PATCH - Locking issues and memory leak

[Benny Halevy]

On Nov. 26, 2007, 8:36 +0200, "Steven Wilton" <steven.wilton at team.eftel.com.au> wrote:
> It looks like the bugs mentioned in my previous 2 posts are related.
> The attached patch fixes the issue by removing the file access checks
> when a lock is requested (since my assumption is that the NFS4 code
> should behave the same as other POSIX code in relation to file locks).

Hmm, according to posix: "A request for an exclusive lock shall fail if the file
descriptor was not opened with write access."

In your original post you say: "we have
noticed that if a program on a NFS client opens a file read-only and
then tries to obtain an exclusive lock on that file, the server logs the
following to the kernel log:

NFSD: preprocess_seqid_op: bad seqid (expected 4, got 5)"

So it seems like the posix compliant server should deny the exclusive lock
but falling into the bad seqid path and certainly leaking memory due to that
is a bug.

> 
> My understanding of the problem from looking at the code is that when
> the lock request fails, the NFS4 server does not increment the
> appropriate sequence counter (normally done in
> alloc_init_lock_stateowner() ) because the call to
> nfs4_preprocess_seqid_op() fails.
> 
> The memory "leak" occurs when the client tries to close the file.  The
> nfs request to close the file fails because the nfs server has not
> incremented its sequence counter.  This results in the NFS server not
> processing the NFS request to close the file, and not releasing the
> memory from the SLAB until the NFS server is shut down.
> 
> 
> My fix will solve the single case where the nfs4_preprocess_seqid_op()
> call fails due to a file lock / open mode mismatch, which may not be
> correct if it breaks the NFS4 specs.  The other fix would be to manually
> increment the sequence counter somewhere else in the code (maybe in
> nfs4_preprocess_seqid_op() or in nfsd4_lock() and any other relevant
> functions if the call to nfs4_preprocess_seqid_op() fails).
> 
> 
> 
> Hope this helps to get the correct fix sooner
> 
> Steven
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4