* Re: [PATCH 1/1] fix d_revalidate oopsen on NFS exports
2011-12-01 6:50 ` [PATCH 1/1] fix d_revalidate oopsen on NFS exports Tyler Hicks
@ 2011-12-01 7:23 ` Chris Dunlop
2011-12-01 8:02 ` Tyler Hicks
1 sibling, 0 replies; 3+ messages in thread
From: Chris Dunlop @ 2011-12-01 7:23 UTC (permalink / raw)
To: Tyler Hicks
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eric Van Hensbergen,
Ron Minnich, Latchesar Ionkov, David Howells, Jan Harkes,
maintainer:CODA FILE SYSTEM, Dave Kleikamp, Petr Vandrovec,
Trond Myklebust, Greg Kroah-Hartman, Al Viro,
v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
codalist-OCorLXSLWn+MVn35/9/JlcWGCVk0P7UB,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, ecryptfs-u79uwXL29TY76Z2rM5mHXA
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 linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 1/1] fix d_revalidate oopsen on NFS exports
2011-12-01 6:50 ` [PATCH 1/1] fix d_revalidate oopsen on NFS exports Tyler Hicks
2011-12-01 7:23 ` Chris Dunlop
@ 2011-12-01 8:02 ` Tyler Hicks
1 sibling, 0 replies; 3+ messages in thread
From: Tyler Hicks @ 2011-12-01 8:02 UTC (permalink / raw)
To: Al Viro
Cc: linux-fsdevel, linux-kernel, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David Howells, Jan Harkes,
maintainer:CODA FILE SYSTEM, Dave Kleikamp, Petr Vandrovec,
Trond Myklebust, Greg Kroah-Hartman, Chris Dunlop, v9fs-developer,
linux-afs, codalist, jfs-discussion, linux-nfs, ecryptfs
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
On 2011-12-01 00:50:25, Tyler Hicks wrote:
> 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?
Sorry, Al. I see that you've already provided those details here:
https://lkml.org/lkml/2011/5/12/337
I was unaware of that thread until now.
Tyler
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread