Re: [PATCH] cifs: implementation id context as negotiate context

Henrique Carvalho
2026-03-06T23:30:44Z

On Fri, Mar 06, 2026 at 05:04:20PM -0600, Steve French wrote:
> On Fri, Mar 6, 2026 at 4:45 PM Henrique Carvalho
> <henrique.carvalho@suse.com> wrote:
> >
> > On Wed, Mar 04, 2026 at 06:04:05PM +0530, Shyam Prasad N wrote: > On Wed, Mar 4, 2026 at 5:59 PM <nspmangalore@gmail.com> wrote: From: Shyam Prasad N <sprasad@microsoft.com>
> > >
> > > A proof-of-concept based on this draft from Bharath.
> > > Looking for comments on how to improve.
> >
> > Looks good.
> >
> > Just one minor thing for now. To me the cifs.ko module version doesn't
> > say much as it seems to be not reliable (apologies if I'm mistaken).
>
> It does get incremented every 10 weeks.
>

Okay. I guess we've skipped sometimes.

> > Also, the same version could have different implementations in different
> > distributions. modinfo -F srcversion cifs is a better way to
> > differentiate cifs versions but not to compare versions. So the solution
> > is either remove this or bump it in every change using X.Y.Z.
>
> We do bump the module version every kernel release, e.g. we are at
> 2.59 in Linux 7.0 (7.0-rc2)
> Would bump it when someone does a 'full backport' of most cifs fixes
> to an earlier kernel.
>
> > Further, have you thought about how the client can use this in its favor
> > other than diagnosing/debugging a faulty server?
>
> I thought this was for the reverse - so the server support team can
> get metrics on whether the client is an old client with known bugs
>
> > I think we need to be clear on what is allowed here, to me it seems
> > quirks, workarounds and perf tuning? Maybe this can be used to improve
> > interaction between linux client and linux server?
>
> presumably primarily for customer support to be able to recognise
> known client problems on clients accessing a server
>

Yes, but also the server will be able to send back context as well,
correct? This may allow more than bug triaging.

--
Henrique
SUSE Labs