At 2016-09-03 21:03:12, "Al Viro" <viro@xxxxxxxxxxxxxxxxxx> wrote:
>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?
?韬{.n?壏煯壄?%娝?檩?w?{.n?壏{饼?z鳐?韰骅w* jg?秹殠娸?G珴?⒏ ⒎:+v墾妛鑚豰稛?? 畐娻＂穐殢鉂?嗁?
