RE: [PATCH v2] NFS: return DENIED in decode_lock_denied if we cannot decode owner

["Frank Filz" <ffilzlnx@mindspring.com>]

The thing is, it may not be a server bug. The protocol specifies a limit of 1024 bytes for the owner opaque. The owner may come from something other than another Linux client.

In fact, as has been pointed out by someone else, Ganesha returns a 21 byte "ganesha_unknown_owner" when the lock owner is not another NFS owner. Obviously we could (and probably will) shorten this, but the owner could just as well come from another client, or be some representation of a local owner. Nothing in the protocol even gives a hint that the owner should be limited to something as small as 20 bytes.

Personally I have wondered of the conflicting lock owner is really useful to anyone anyway. Obviously the Linux client does nothing with it (which really is reasonable since the POSIX fcntl call only allows for returning a pid). I guess there might be some use in a tcpdump trace (but even there, one might argue it would be nice to see the IP address of the client holding the conflicting lock along with its [probably 20 byte] lock owner).

Frank

-----Original Message-----
From: Jeff Layton [mailto:jlayton@kernel.org] 
Sent: Thursday, September 17, 2026 5:24 AM
To: Roberto Bergantinos Corpas <rbergant@redhat.com>; trondmy@kernel.org; anna@kernel.org
Cc: neil@brown.name; prabhakar.pujeri@dell.com; linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2] NFS: return DENIED in decode_lock_denied if we cannot decode owner

...  

Typically, we don't work around server bugs in the client (and vice versa), but I think this is a reasonable thing to do in this case since we don't use remote lockowner information anywhere in the kernel.

Reviewed-by: Jeff Layton <jlayton@kernel.org>