On Sun, 2009-05-17 at 04:44 +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13330 > > Summary: nfs4 NULL pointer dereference in _nfs4_do_setlk > Product: File System > Version: 2.5 > Kernel Version: 2.6.30-rc4 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: NFS > AssignedTo: trond.myklebust@xxxxxxxxxx > ReportedBy: rercola@xxxxxxxxxxx > Regression: No > > > Created an attachment (id=21380) > --> (http://bugzilla.kernel.org/attachment.cgi?id=21380) > NFSv4 BUG ON log > > My NFS server rebooted. > > The machine with the kernel in question, one of many clients, spit out the > attached error in dmesg, and all NFS activity on the machine blocked forever, > necessitating a reboot. > > This is not true on any of the other NFS clients on the network, which vary > between 2.6.18 and 2.6.27, so it may be A) 64-bit specific somehow (the rest > are 32-bit), B) recently introduced, or C) recently exposed by some existing > bad behavior in NFS recovery being removed. > > Machine was "vanilla" 2.6.30-rc4 (with commits > b827e496c893de0c0f142abfaeb8730a2fd6b37f and > 7fdf523067666b0eaff330f362401ee50ce187c4 added), 64-bit. NFSv4 mounted with > rw,nosuid,nodev,noatime,hard,intr,nolock,sloppy,rsize=8192,wsize=8192,tcp,timeo=600. > > I'll try reproducing this on latest GIT shortly, but it's hard to reproduce > (since it only occurs after the NFS server reboots, and not even consistently > then), so I don't know when I'll be able to report back that it occurs or not. Switching to email... I'm having trouble reproducing this, and staring at the code itself isn't helping (as far as I can see, the locking using nfsi->rwsem should work). Could you therefore please try the attached patch? Cheers Trond
Attachment:
linux-2.6.30-007-fix_nfsv4_setlock_oops.dif
Description: NFSv4: Fix an Oops in the lock recovery code
