lkml.org 
[lkml]   [2014]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux 3.15 .. and continuation of merge window
Date

Al Viro:
> So I suspect that the right fix is a bit trickier - in addition to check
> on the fast path (i.e. when trylock gets us the lock on parent), we need
> to
> * get rcu_read_lock() before dropping ->d_lock.
> * check if dentry is already doomed right after taking rcu_read_lock();
> if not, any value we might see in ->d_parent afterwards will point to object
> not freed until we drop rcu_read_lock.
>
> IOW, something like the delta below. Comments?

I will try testing later.
For now, as a comment before testing, the patch looks weird for me. It
checks d_lockref.count twice during d_lockref.lock held. It must be the
same result, isn't it? Or does it mean that denty can be handled by
lockref_mark_dead() even if d_lockref.lock is held?


J. R. Okajima


\
 
 \ /
  Last update: 2014-06-11 12:01    [W:1.222 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site