Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()
On Fri, Feb 23, 2018 at 03:12:14AM +, Al Viro wrote:
> failed:
> spin_unlock(&dentry->d_lock);
> spin_lock(&inode->i_lock);
> spin_lock(&dentry->d_lock);
> parent = lock_parent(dentry);
Hmm... Negative dentry case obviously is trickier - not to mention oopsen,
it might have become positive under us. Bugger... OTOH, it's not much
trickier - with negative dentry we can only fail on trying to lock the
parent, in which case we should just check that it's still negative before
killing it off. If it has gone positive on us, we'll just unlock the
parent and we are back to the normal "positive dentry, only ->d_lock held"
case. At most one retry there - once it's positive, it stays positive.
So,
static struct dentry *dentry_kill(struct dentry *dentry)
__releases(dentry->d_lock)
{
struct inode *inode = dentry->d_inode;
struct dentry *parent = NULL;
if (inode && unlikely(!spin_trylock(&inode->i_lock)))
goto no_locks;
if (!IS_ROOT(dentry)) {
parent = dentry->d_parent;
if (unlikely(!spin_trylock(&parent->d_lock))) {
if (inode) {
spin_unlock(&inode->i_lock);
goto no_locks;
}
goto need_parent;
}
}
kill_it:
__dentry_kill(dentry);
return parent;
no_locks: /* positive, only ->d_lock held */
spin_unlock(&dentry->d_lock);
spin_lock(&inode->i_lock);
spin_lock(&dentry->d_lock);
need_parent:
parent = lock_parent(dentry);
if (unlikely(dentry->d_lockref.count != 1 || retain_dentry(dentry))) {
/* we are keeping it, after all */
if (inode)
spin_unlock(&inode->i_lock);
spin_unlock(&dentry->d_lock);
if (parent)
spin_unlock(&parent->d_lock);
return NULL;
}
/* it should die */
if (inode) /* was positive, ->d_inode unchanged, locks held */
goto kill_it;
inode = dentry->d_inode;// READ_ONCE?
if (!inode) /* still negative, locks held */
goto kill_it;
/* negative became positive; it can't become negative again */
if (parent)
spin_unlock(&parent->d_lock);
goto no_locks; /* once */
}
Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()
On Fri, Feb 23, 2018 at 03:12:14AM +, Al Viro wrote: > /* retain_dentry() needs ->count == 1 already checked) ... obviously not even compile-tested ;-)
Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()
On Fri, Feb 23, 2018 at 02:22:43AM +, Al Viro wrote:
> No. This is completely wrong. If somebody else has found the sucker
> while we dropped the lock and even got around to playing with refcount,
> they might have done more than that.
>
> In particular, they might have *dropped* their reference, after e.g.
> picking it as our inode's alias and rehashed the fucker. Making
> our decision not to retain it no longer valid. And your code will
> not notice that.
PS: I really wonder if we should treat the failure to trylock ->i_lock
and parent's ->d_lock at that point (we are already off the fast path
here) as
* drop all spinlocks we'd got
* grab ->i_lock
* grab ->d_lock
* lock_parent()
* act as if fast_dput() has returned 0, only remember to drop ->i_lock
and unlock parent before dropping ->d_lock if we decide to keep it.
IOW, add
static inline bool retain_dentry(struct dentry *dentry)
{
WARN_ON(d_in_lookup(dentry));
/* Unreachable? Get rid of it */
if (unlikely(d_unhashed(dentry)))
return false;
if (unlikely(dentry->d_flags & DCACHE_DISCONNECTED))
return false;
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE)) {
if (dentry->d_op->d_delete(dentry))
return false;
}
dentry_lru_add(dentry);
dentry->d_lockref.count--;
return true;
}
then have dput() do
{
if (unlikely(!dentry))
return;
repeat:
might_sleep();
rcu_read_lock();
if (likely(fast_dput(dentry))) {
rcu_read_unlock();
return;
}
/* Slow case: now with the dentry lock held */
rcu_read_unlock();
if (likely(retain_dentry(dentry))) {
spin_unlock(&dentry->d_lock);
return;
}
dentry = dentry_kill(dentry);
if (dentry)
goto repeat;
}
with dentry_kill() being pretty much as it is now, except that
it would be ending on
failed:
spin_unlock(&dentry->d_lock);
spin_lock(&inode->i_lock);
spin_lock(&dentry->d_lock);
parent = lock_parent(dentry);
/* retain_dentry() needs ->count == 1 already checked)
if (dentry->d_lockref.count == 1 && !retain_dentry(dentry)) {
__dentry_kill(dentry);
return parent;
}
/* we are keeping it, after all */
if (inode)
spin_unlock(&inode->i_lock);
spin_unlock(&dentry->d_lock);
if (parent)
spin_unlock(&parent->d_lock);
return NULL;
}
Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()
On Fri, Feb 23, 2018 at 12:50:23AM +0100, John Ogness wrote:
> static struct dentry *dentry_kill(struct dentry *dentry)
> __releases(dentry->d_lock)
> {
> - struct inode *inode = dentry->d_inode;
> - struct dentry *parent = NULL;
> + int saved_count = dentry->d_lockref.count;
Umm... How can that be not 1? After all, fast_dput() should
never return false without ->d_lock being held *and* ->d_count being
equal to 1.
> + /*
> + * d_inode might have changed if d_lock was temporarily
> + * dropped. If it changed it is necessary to start over
> + * because a wrong inode (or no inode) lock is held.
> + */
If it might have changed, we are fucked.
> +out_ref_changed:
> + /*
> + * The refcount was incremented while dentry->d_lock was dropped.
> + * Just decrement the refcount, unlock, and tell the caller to
> + * stop the directory walk.
> + */
> + if (!WARN_ON(dentry->d_lockref.count < 1))
> + dentry->d_lockref.count--;
> +
> spin_unlock(&dentry->d_lock);
> - return dentry; /* try again with same dentry */
> +
> + return NULL;
No. This is completely wrong. If somebody else has found the sucker
while we dropped the lock and even got around to playing with refcount,
they might have done more than that.
In particular, they might have *dropped* their reference, after e.g.
picking it as our inode's alias and rehashed the fucker. Making
our decision not to retain it no longer valid. And your code will
not notice that.
