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
Attachment:
signature.asc
Description: Digital signature
