Al Viro:
> The former guarantees that the address we are doing trylock on would be that
> of a live dentry. The latter makes sure that anything assigned to
> dentry->d_parent after we drop ->d_lock will not be freed until we drop
> rcu_read_lock.
Although I don't know how to reproduce the probl
On Wed, Jun 11, 2014 at 06:32:58PM +0900, J. R. Okajima wrote:
>
> 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.
> >
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()
On Mon, Jun 09, 2014 at 12:30:34PM +0900, J. R. Okajima wrote:
>
> Linus Torvalds:
> > So I ended up doing an rc8 because I was a bit worried about some
> > last-minute dcache fixes, but it turns out that nobody seemed to even
> > notice those. We did have other issues during the week, though, so
Linus Torvalds:
> So I ended up doing an rc8 because I was a bit worried about some
> last-minute dcache fixes, but it turns out that nobody seemed to even
> notice those. We did have other issues during the week, though, so it
:::
I am afraid there is a problem in dcache. Please read
htt
So I ended up doing an rc8 because I was a bit worried about some
last-minute dcache fixes, but it turns out that nobody seemed to even
notice those. We did have other issues during the week, though, so it
was just as well. The futex fixes and cleanups may stand out, but as
usual there's various ot
6 matches
Mail list logo
