Is RCU not safe enough to protect dcache hlist?
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
Quoted 4 lines · Lee
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_lookupusing
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
Quoted 7 lines · Valdis.Kletnieks at vt.edu
Quoted 4 lines · Lee
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_lookupusing
sequence lock to protect the hlist again?
Quoted 5 lines
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 :-)