[PATCH][smb3 client] log less confusing message on multichannel mounts to Samba when no interfaces returned

[Steve French]

attached wrong patch - resending


On Mon, Oct 3, 2022 at 5:32 PM Steve French <smfrench at gmail.com> wrote:
>
> updated patch to:
> 1) log the server name for this message
> 2) only log on mount (not every ten minutes)
>
> See attached
>
> On Mon, Oct 3, 2022 at 9:21 AM Tom Talpey <tom at talpey.com> wrote:
> >
> > On 10/3/2022 12:38 AM, Steve French wrote:
> > > On Sat, Oct 1, 2022 at 6:22 PM Tom Talpey <tom at talpey.com> wrote:
> > >>
> > >> On 10/1/2022 12:54 PM, Steve French wrote:
> > >>> Some servers can return an empty network interface list so, unless
> > >>> multichannel is requested, no need to log an error for this, and
> > >>> when multichannel is requested on mount but no interfaces, log
> > >>> something less confusing.  For this case change
> > >>>      parse_server_interfaces: malformed interface info
> > >>> to
> > >>>      empty network interface list returned by server
> > >>
> > >> Will this spam the log if it happens on every MC refresh (10 mins)?
> > >> It might be helpful to identify the servername, too.
> > >
> > > Yes - I just noticed that in this case (multichannel mount to Samba
> > > where no valid interfaces) we log it every ten minutes.
> > > Maybe best way to fix this is to change it to a log once error (with
> > > server name is fine with me) since it is probably legal to return an
> > > empty list (so not serious enough to be worth logging every ten
> > > minutes) and in theory server could fix its interfaces later.
> >
> > Ten minutes is the default recommended polling interval in the doc.
> >
> > While it's odd, it's not prevented by the protocol. I could guess
> > that a server running in a namespace might return strange things
> > as devices came and went, for example.
> >
> > It's not an error, so the message is purely informational. It is
> > useful though. Is it possible to suppress the logging if the
> > message *doesn't* change, but otherwise emit new ones? That might
> > require some per-server fiddling to avoid multiple servers flipping
> > the message.
> >
> > A boolean or bit in the server struct? A little ugly for the purpose,
> > but surfacing multichannel events - especially ones that prevent it
> > from happening - seems worthwhile.
> >
> > Tom.
> >
> >
> > Tom.
> >
> >
> > >>> Cc: <stable at vger.kernel.org>
> > >>> Signed-off-by: Steve French <stfrench at microsoft.com>
> > >>>
> > >>> See attached patch
> > >>>
> > >
> > >
> > >
>
>
>
> --
> Thanks,
>
> Steve



-- 
Thanks,

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-smb3-do-not-log-confusing-message-when-server-return.patch
Type: text/x-patch
Size: 4090 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20221003/1a9dfe92/0001-smb3-do-not-log-confusing-message-when-server-return.bin>