On Fri, Jan 14, 2011 at 2:03 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 14, 2011 at 01:57:55PM +1100, Nick Piggin wrote: >> On Fri, Jan 14, 2011 at 1:03 AM, J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote: >> > >> > NFSD calls filesystem's ->d_revalidate() with the parameter nd == NULL. >> > So every >> > ? ? ? ?if (nd->flags & LOOKUP_RCU) >> > ? ? ? ? ? ? ? ?return -ECHILD; >> > code which was added to ->d_revalidate() of FS which supports NFS >> > exporting will crash. >> > >> > If we rewrite it as >> > ? ? ? ?if (nd && (nd->flags & LOOKUP_RCU)) >> > ? ? ? ? ? ? ? ?return -ECHILD; >> > the problem may not occur. >> > But I am not sure whether lookup_one_len() call in NFSD support rcu-walk. >> >> Ah, good catch. >> >> I'm going to change the d_revalidate API so it takes and inode and rcu-walk >> flag parameter to make it easier for filesystems to implement rcu-walk. >> >> That will take care of this NULL nd case. > > Oh, for fuck sake... Would you at least mind posting your API change > description to fsdevel before going for it? Of course. I was discussing it with Miklos yesterday too, but haven't finished getting a proposal together. The main idea here would be to just pass in a flags parameter rather thank poking in nd to get the rcu-walk status. That would solve this problem and also avoid nd for most filesystems that don't care about it. > ->d_revalidate() is one sick puppy and it's intimately involved in atomic > open rewrite. Please, *please* don't make that shit even messier... Right, I did agree with Miklos that using nd for passing rcu-walk status was going in the wrong direction with that API. Do you agree? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
