On Thu, Dec 01, 2011 at 12:50:25AM -0600, Tyler Hicks wrote: > On 2011-11-29 19:25:01, Chris Dunlop wrote: >> 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. Actually, no, it wasn't eCryptfs or another stacked filesystem. It seems my dirty little secret must come out: I hit the problem when trying to use the (necessarily) out-of-tree zfsonlinux (ZoL) [1], on an NFS root machine. I don't know exactly what ZoL is using lookup_one_len() for, nor how to fix it so it isn't, but I've given them the heads up that it's not supposed to be used outside of original file system [2]. Chris. [1] http://zfsonlinux.org/ [2] https://github.com/zfsonlinux/zfs/issues/456 -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
