bad sequence-id error's since at least 2.6.28-rc5

[J. Bruce Fields]

On Tue, Jan 06, 2009 at 11:16:16AM -0500, Trond Myklebust wrote:
> The client first does an OPEN for read only using a new openowner, and a
> SEQID of 0. The server responds OK, and requests an OPEN_CONFIRM.
> 
> The client then sends the OPEN_CONFIRM using a SEQID of 1. The server
> responds OK. So far so good.
> 
> The client then requests an exclusive LOCK (write lock). It uses the
> open_to_lockowner request, which requires it to send the open stateid,
> and uses a seqid of 2.
> The server rejects the exclusive lock request with an NFS4ERR_OPENMODE
> reply, since you don't have the file open for writing. That part is
> correct, and follows the spec. (btw, the reason the client is sending
> this is probably because you are calling flock(LOCK_EX). While that is
> allowed on local filesystems, we cannot unfortunately support it over
> NFSv4)
> 
> The client then sends a CLOSE with a seqid of 3. At that point, the
> server returns the bad-sequence id error, which is definitely a server
> bug. NFS4ERR_OPENMODE is not on the list of exceptional errors in
> section 8.1.5 of rfc3530, so the client was quite correct in bumping the
> sequence id from 2 to 3.
> 
> Bruce, is this a known problem with 2.6.24 servers, and has it been
> fixed in mainline yet?

Looked totally unfamiliar to me, but look:

	39325bd03fc "nfsd4: fix bad seqid on lock request incompatible
	with open mode

	"The failure to return a stateowner from
	nfs4_preprocess_seqid_op() means in the case where a lock
	request is of a type incompatible with an open (due to, e.g., an
	application attempting a write lock on a file open for read),
	means that fs/nfsd/nfs4xdr.c:ENCODE_SEQID_OP_TAIL() never bumps
	the seqid as it should.  The client, attempting to close the
	file afterwards, then gets an (incorrect) bad sequence id error.
	Worse, this prevents the open file from ever being closed, so we
	leak state.
				    
	"Thanks to Benny Halevy and Trond Myklebust for analysis, and to
	Steven Wilton for the report and extensive data-gathering."

Apparently I fixed this, then promptly forgot the whole thing.  I have
no memory.

Anyway, this should be fixed in 2.6.25.

--b.