Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Linus Torvalds]

On Thu, May 29, 2014 at 6:30 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Great...  OK, saner splitup of that sucker (equivalent to combination of
> these two patches) is in vfs.git#for-linus.
>
> Review and testing would be very welcome.

So looking at the "dealing with the rest of shrink_dentry_list()
livelock" patch, I think the "release the parents" case is now big and
complicated enough to be split into a function of its own.

However, I have a bigger question too: the "release the parent" case
_should_ be possible to do with just a "dput()" on the parent, and the
only reason we're doing the special case is that since we are
shrinking things, we try to be more aggressive and shrink all the
parents if possible. Right?

If so, though, that brings up two questions:

 (a) do we really want to be that aggressive? Can we ever traverse
_past_ the point we're actually trying to shrink in
shrink_dcache_parent()?

 (b) why does the "dput()" (or rather, the dentry_kill()) locking
logic have to retain the old trylock case rather than share the parent
locking logic?

I'm assuming the answer to (b) is that we can't afford to drop the
dentry lock in dentry_kill(), but I'd like that answer to the "Why" to
be documented somewhere.

I don't much care what the answer to (a) is, but again, it would be
good to have that mentioned somewhere.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/