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

[Steve French]

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
-------------- 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: 3933 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20221003/60c0d251/0001-smb3-do-not-log-confusing-message-when-server-return.bin>