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

[Paulo Alcantara <pc@manguebit.org>]

Steve French <smfrench@gmail.com> writes:

> 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.
>
>> 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.

Who?

>> 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

The client version is entirely pointless, especially for distribution
kernels.  The support team can't figure out by just looking at the
client version as the backports are what really matter in terms of a
distro kernel.  Most distro kernels don't even bother backporting those
commits that bump the client version, which makes it even more
inaccurate.

>> 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

Neither the client or kernel version will tell you _exactly_ where the
problem is in distro kernels.