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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
