Is RCU not safe enough to protect dcache hlist?

Is RCU not safe enough to protect dcache hlist?

[Lee]

Hi, all:

I am studying the dcache in VFS recently . I found that hlist of dcache
is already protected by RCU in
  __d_lookup.Is it necessary  for the function -- d_lookup using
sequence lock to protect the hlist again?

struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
{
     struct dentry * dentry = NULL;
     unsigned long seq;

         do {
                 seq = read_seqbegin(&rename_lock);
                 dentry = __d_lookup(parent, name);
                 if (dentry)
             break;
     } while (read_seqretry(&rename_lock, seq));
     return dentry;
}

Thanks
---
Rock Lee

Is RCU not safe enough to protect dcache hlist?

[Valdis.Kletnieks at vt.edu]

On Mon, 16 Mar 2015 10:06:37 +0800, Lee said:

> I am studying the dcache in VFS recently . I found that hlist of dcache
> is already protected by RCU in
>   __d_lookup.Is it necessary  for the function -- d_lookup using
> sequence lock to protect the hlist again?

RCU is useful when you can tolerate a bit of latency in other users
finding out about updated values and/or slightly stale values.  That's
not an option for d_lookup(), which has to check the most recent value
in order to avoid race conditions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150316/076571ec/attachment.bin 

Is RCU not safe enough to protect dcache hlist?

[Lee]

On 2015/3/16 14:02, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 16 Mar 2015 10:06:37 +0800, Lee said:
>
>> I am studying the dcache in VFS recently . I found that hlist of dcache
>> is already protected by RCU in
>>    __d_lookup.Is it necessary  for the function -- d_lookup using
>> sequence lock to protect the hlist again?
>
> RCU is useful when you can tolerate a bit of latency in other users
> finding out about updated values and/or slightly stale values.  That's
> not an option for d_lookup(), which has to check the most recent value
> in order to avoid race conditions.
>
In __d_lookup(), one hlist is protected well with RCU. But this is not 
enough for the dentry_hashtable, so d_lookup() uses some mechanism to 
protect the dentry_hashtable, in this condition, the mechanism is 
sequence lock :-)