On Sat, Sep 03, 2016 at 06:46:05PM +0800, shyodx1989 wrote:
>
> But most filesystems, which have d_revalidate, return -ECHILD if LOOKUP_RCU is set instead of
> checking if it is safe for rcu-walk.
For a good and simple reason that the work they would have to do in their
->d_revalidate() can't be done without blocking. Which can't be done under
rcu_read_lock(), thus the "sorry, you have to leave RCU mode for that", aka
-ECHILD.
>However commit 5c0f360b083fb33d05d1bff4b138b82d715eb419
> "jfs_ci_revalidate() is safe from RCU mode" removes the check. So why is jfs_ci_revalidate safe in
> RCU mode
Because JFS ->d_revalidate() doesn't need anything blocking.
> and if we only check d_inode (like the following code), what should we care about to
> tell if d_revalidate is safe for rcu-walk or not and? Ref-walk is much slower than rcu-walk, maybe
> it's better not to return -ECHILD directly if not necessary.
>
>
> d_revalidate(dentry, flags)
> {
> if (flags & LOOKUP_RCU)
> return -ECHILD
> if (!d_inode_rcu(dentry))
> return 0;
> return 1;
> }
Huh? Which filesystem would that be? Sure, in such case -ECHILD is pointless;
who does that? Some of them might be possible to drop ECHILD, but that needs
some care. Note, BTW, that things like dput() are blocking, so the things like
trying to grab parent, etc. can get tricky.
Which ->d_revalidate() instance do you have in mind?
--
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
