On May 3, 2013, at 12:18 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Fri, 2013-05-03 at 12:12 -0400, Chuck Lever wrote: >> Hi- >> >> On May 2, 2013, at 1:19 PM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: >> >>> If a NFS client receives a delegation for a file after it has taken >>> a lock on that file, we can currently end up in a situation where >>> we mistakenly skip unlocking that file. >>> >>> The following patch swaps an erroneous check in nfs4_proc_unlck for >>> whether or not the file has a delegation to one which checks whether >>> or not we hold a lock stateid for that file. >>> >>> Reported-by: Chuck Lever <Chuck.Lever@xxxxxxxxxx> >>> Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> >>> Cc: stable@xxxxxxxxxxxxxxx >> >> Although this patch may apply cleanly to, say, 3.0-stable, the result is that LOCKUs now never appear on the wire. It seems that older stable kernels are missing something that is needed to make this simple fix work correctly. > > Yes. There is a dependency on commit > 795a88c968eef031f370973512b42124bacb2f17 (NFSv4: Convert the > nfs4_lock_state->ls_flags to a bit field). For the record, 795a88c9 appears in 3.7. Thus the specific patch proposed in this thread applies to 3.7, 3.8, and 3.9. We applied this patch to a 3.0-based kernel and then adjusted for the absence of 795a88c9. It works as expected. We'll also check as far back as 2.6.32. More later. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
