Messages in this thread | | | Date | Thu, 1 Dec 2011 00:50:25 -0600 | From | Tyler Hicks <> | Subject | Re: [PATCH 1/1] fix d_revalidate oopsen on NFS exports |
| |
On 2011-11-29 19:25:01, Chris Dunlop wrote: > Hi, > > I haven't seen any response to this patch which fixes an Oops in > d_revalidate. I hit this using NFS, but various other file > systems look to be likewise vulnerable, hence the broadness of > the patch. The sequence leading to the Oops is: > > lookup_one_len() [fs/namei.c] > calls __lookup_hash() [fs/namei.c] with nd == NULL, > which can then call the file system specific d_revalidate(), passing in nd == NULL > which will then Oops if nd is used without checking
Hey Chris - Can you share what you were trying to do when you hit this? Were you stacking eCryptfs on top of NFS? Another stacked filesystem on top of NFS?
Do you *need* a stacked filesystem to work on top of NFS? If so, we'll need to discuss a way forward. Al has previously shown a dislike of eCryptfs passing around nameidata (for good reason), but that is what NFS currently requires. I looked at doing this a few months back, but never got to the implementation stage.
As David mentioned, Al's atomic open patches might solve all of this in the future, but I don't know much about that patchset. Is there any relevant info you could provide about those patches, Al?
Tyler [unhandled content-type:application/pgp-signature] | |