wrong stateid used after flock lock taken

Hi Jeff et al.

I think your patch
Commit: 8003d3c4aaa5 ("nfs4: treat lock owners as opaque values")

introduced a regression ... or maybe exposed a latent problem.

The particular symptom that I can demonstrate is that if I open a file with NFSv4, take a flock() exclusive lock, and then write to the file, then the WRITE request uses the stateid returned by OPEN, not the one returned by LOCK.

The Linux NFS server doesn't have a problem with that, but some NFS servers do (one returns NFS4ERR_LOCKED, which seems to imply it imposes mandatory locking!).
In any case, this is the wrong stateid to use.

The patch changed nfs4_copy_lock_stateid() so it was more restrictive in the stateids it allowed.
I must admit that I find the code that you removed incredibly confusing. I defined a union field
- pid_t flock_owner;

and I cannot understand how a pid_t would be relevant for a flock_owner, as the flock is tied to the 'struct file', not the pid.

Anyway, a write request includes an 'nfs_lock_context' and from that we need to somehow find the correct stateid.
I'm wondering if nfs4_set_rw_stateid() should call nfs4_select_rw_stateid() twice, once to look for a flock stated, and once to look for a posix-lock stateid .... or something like that.

I'll take a fresh look at the code next week and maybe it will be easier to understand then, but meanwhile if you have any suggestions I'd be very happy to hear them.

Thanks,
NeilBrown

Quoted 32 lines · NeilBrown

Hi Jeff et al.

I think your patch
Commit: 8003d3c4aaa5 ("nfs4: treat lock owners as opaque values")

introduced a regression ... or maybe exposed a latent problem.

The particular symptom that I can demonstrate is that if I open a file with NFSv4, take a flock() exclusive lock, and then write to the file, then the WRITE request uses the stateid returned by OPEN, not the one returned by LOCK.

The Linux NFS server doesn't have a problem with that, but some NFS servers do (one returns NFS4ERR_LOCKED, which seems to imply it imposes mandatory locking!).
In any case, this is the wrong stateid to use.

The patch changed nfs4_copy_lock_stateid() so it was more restrictive in the stateids it allowed.
I must admit that I find the code that you removed incredibly confusing. I defined a union field
- pid_t flock_owner;

and I cannot understand how a pid_t would be relevant for a flock_owner, as the flock is tied to the 'struct file', not the pid.

Anyway, a write request includes an 'nfs_lock_context' and from that we need to somehow find the correct stateid.
I'm wondering if nfs4_set_rw_stateid() should call nfs4_select_rw_stateid() twice, once to look for a flock stated, and once to look for a posix-lock stateid .... or something like that.

Quoted 6 lines

I'll take a fresh look at the code next week and maybe it will be easier to understand then, but meanwhile if you have any suggestions I'd be very happy to hear them.

Thanks,
NeilBrown

(cc'ing Ben...)

I'll plan to give this another look as well. Maybe there's some way to do this more sanely that we can get Trond to accept? The catch is that read and write are both hot paths to some degree so we don't want to overly burden the client in those codepaths if we can help it...

Ben Coddington had some patches a a few months ago (April?) that would have made OFD locks work properly witn NFSv4. Trond NAK'ed them at the time, but perhaps we should give those another look. OFD and flock locks both use the filp pointer as the owner, so those patches might also have fixed this case.