From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Miklos Szeredi <mszeredi@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
Date: Wed, 28 May 2014 19:39:54 +0100 [thread overview]
Message-ID: <20140528183954.GA18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140528141937.GZ18016@ZenIV.linux.org.uk>
On Wed, May 28, 2014 at 03:19:37PM +0100, Al Viro wrote:
> OK, it's not ->i_lock, it's ->d_lock on parent being grabbed after that on
> child, while d_walk() keeps taking them in opposite order. Hmm...
>
> In principle we could do the following:
> * split dentry_kill() into the part that is taking locks and
> the rest of it.
> * in case of trylock failure have shrink_dentry_list() do
> read_seqlock_excl(&rename_lock) (which will stabilize ->d_parent) and
> take ->d_lock in the right order, drop rename_lock and call __dentry_kill().
>
> AFAICS, that would kill the livelock for good. We still have ->i_lock
> trylock failures to deal with, but those are less of a problem - d_walk()
> won't step on ->i_lock at all. I'm going to grab a couple of hours of sleep
> and try to put together something along those lines...
OK, the warnings about averting your eyes very much apply; the thing below
definitely needs more massage before it becomes acceptable (and no, it's
not a single commit; I'm not that insane), but it changes behaviour in the
way described above. Could you check if the livelock persists with it?
No trace-generating code in there, so the logs should be compact enough...
diff --git a/fs/dcache.c b/fs/dcache.c
index 42ae01e..ed0cc62 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -441,42 +441,12 @@ void d_drop(struct dentry *dentry)
}
EXPORT_SYMBOL(d_drop);
-/*
- * Finish off a dentry we've decided to kill.
- * dentry->d_lock must be held, returns with it unlocked.
- * If ref is non-zero, then decrement the refcount too.
- * Returns dentry requiring refcount drop, or NULL if we're done.
- */
-static struct dentry *
-dentry_kill(struct dentry *dentry, int unlock_on_failure)
- __releases(dentry->d_lock)
+static void __dentry_kill(struct dentry *dentry)
{
- struct inode *inode;
struct dentry *parent = NULL;
bool can_free = true;
-
- if (unlikely(dentry->d_flags & DCACHE_DENTRY_KILLED)) {
- can_free = dentry->d_flags & DCACHE_MAY_FREE;
- spin_unlock(&dentry->d_lock);
- goto out;
- }
-
- inode = dentry->d_inode;
- if (inode && !spin_trylock(&inode->i_lock)) {
-relock:
- if (unlock_on_failure) {
- spin_unlock(&dentry->d_lock);
- cpu_relax();
- }
- return dentry; /* try again with same dentry */
- }
if (!IS_ROOT(dentry))
parent = dentry->d_parent;
- if (parent && !spin_trylock(&parent->d_lock)) {
- if (inode)
- spin_unlock(&inode->i_lock);
- goto relock;
- }
/*
* The dentry is now unrecoverably dead to the world.
@@ -520,10 +490,44 @@ relock:
can_free = false;
}
spin_unlock(&dentry->d_lock);
-out:
if (likely(can_free))
dentry_free(dentry);
+}
+
+/*
+ * Finish off a dentry we've decided to kill.
+ * dentry->d_lock must be held, returns with it unlocked.
+ * If ref is non-zero, then decrement the refcount too.
+ * Returns dentry requiring refcount drop, or NULL if we're done.
+ */
+static struct dentry *
+dentry_kill(struct dentry *dentry, int unlock_on_failure)
+ __releases(dentry->d_lock)
+{
+ struct inode *inode = dentry->d_inode;
+ struct dentry *parent = NULL;
+
+ if (inode && unlikely(!spin_trylock(&inode->i_lock)))
+ goto failed;
+
+ if (!IS_ROOT(dentry)) {
+ parent = dentry->d_parent;
+ if (unlikely(!spin_trylock(&parent->d_lock))) {
+ if (inode)
+ spin_unlock(&inode->i_lock);
+ goto failed;
+ }
+ }
+
+ __dentry_kill(dentry);
return parent;
+
+failed:
+ if (unlock_on_failure) {
+ spin_unlock(&dentry->d_lock);
+ cpu_relax();
+ }
+ return dentry; /* try again with same dentry */
}
/*
@@ -797,6 +801,7 @@ static void shrink_dentry_list(struct list_head *list)
struct dentry *dentry, *parent;
while (!list_empty(list)) {
+ struct inode *inode;
dentry = list_entry(list->prev, struct dentry, d_lru);
spin_lock(&dentry->d_lock);
/*
@@ -815,23 +820,52 @@ static void shrink_dentry_list(struct list_head *list)
continue;
}
- parent = dentry_kill(dentry, 0);
- /*
- * If dentry_kill returns NULL, we have nothing more to do.
- */
- if (!parent)
+
+ if (unlikely(dentry->d_flags & DCACHE_DENTRY_KILLED)) {
+ bool can_free = dentry->d_flags & DCACHE_MAY_FREE;
+ spin_unlock(&dentry->d_lock);
+ if (can_free)
+ dentry_free(dentry);
continue;
+ }
- if (unlikely(parent == dentry)) {
- /*
- * trylocks have failed and d_lock has been held the
- * whole time, so it could not have been added to any
- * other lists. Just add it back to the shrink list.
- */
+ inode = dentry->d_inode;
+ if (inode && unlikely(!spin_trylock(&inode->i_lock))) {
d_shrink_add(dentry, list);
spin_unlock(&dentry->d_lock);
continue;
}
+
+ if (IS_ROOT(dentry)) {
+ __dentry_kill(dentry);
+ continue;
+ }
+
+ parent = dentry->d_parent;
+ if (unlikely(!spin_trylock(&parent->d_lock))) {
+ if (inode)
+ spin_unlock(&inode->i_lock);
+ d_shrink_add(dentry, list);
+ spin_unlock(&dentry->d_lock);
+ read_seqlock_excl(&rename_lock);
+ parent = NULL;
+ if (!IS_ROOT(dentry)) {
+ parent = dentry->d_parent;
+ spin_lock(&parent->d_lock);
+ }
+ spin_lock(&dentry->d_lock);
+ read_sequnlock_excl(&rename_lock);
+ inode = dentry->d_inode;
+ if (inode && unlikely(!spin_trylock(&inode->i_lock))) {
+ if (parent)
+ spin_unlock(&parent->d_lock);
+ spin_unlock(&dentry->d_lock);
+ continue;
+ }
+ d_shrink_del(dentry);
+ }
+
+ __dentry_kill(dentry);
/*
* We need to prune ancestors too. This is necessary to prevent
* quadratic behavior of shrink_dcache_parent(), but is also
next prev parent reply other threads:[~2014-05-28 18:39 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 9:37 fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667] Mika Westerberg
2014-05-26 13:57 ` Al Viro
2014-05-26 14:29 ` Mika Westerberg
2014-05-26 14:29 ` Mika Westerberg
2014-05-26 15:27 ` Al Viro
2014-05-26 16:42 ` Al Viro
2014-05-26 18:17 ` Linus Torvalds
2014-05-26 18:26 ` Al Viro
2014-05-26 20:24 ` Linus Torvalds
2014-05-27 1:40 ` Al Viro
2014-05-27 3:14 ` Al Viro
2014-05-27 4:00 ` Al Viro
2014-05-27 7:04 ` Mika Westerberg
2014-05-27 7:04 ` Mika Westerberg
2014-05-28 3:19 ` Al Viro
2014-05-28 7:37 ` Mika Westerberg
2014-05-28 11:57 ` Al Viro
2014-05-28 13:11 ` Mika Westerberg
2014-05-28 14:19 ` Al Viro
2014-05-28 18:39 ` Al Viro [this message]
2014-05-28 19:43 ` Linus Torvalds
2014-05-28 20:02 ` Linus Torvalds
2014-05-28 20:25 ` Al Viro
2014-05-29 10:42 ` Mika Westerberg
2014-05-28 20:14 ` Al Viro
2014-05-28 21:11 ` Linus Torvalds
2014-05-28 21:28 ` Al Viro
2014-05-29 3:11 ` Al Viro
2014-05-29 3:52 ` Al Viro
2014-05-29 5:34 ` Al Viro
2014-05-29 10:51 ` Mika Westerberg
2014-05-29 10:51 ` Mika Westerberg
2014-05-29 11:04 ` Mika Westerberg
2014-05-29 13:30 ` Al Viro
2014-05-29 14:56 ` Mika Westerberg
2014-05-29 15:10 ` Linus Torvalds
2014-05-29 15:44 ` Al Viro
2014-05-29 16:23 ` Al Viro
2014-05-29 16:29 ` Linus Torvalds
2014-05-29 16:53 ` Al Viro
2014-05-29 18:52 ` Al Viro
2014-05-29 19:14 ` Linus Torvalds
2014-05-30 4:50 ` Al Viro
2014-05-30 5:00 ` Linus Torvalds
2014-05-30 6:49 ` Al Viro
2014-05-30 8:12 ` Mika Westerberg
2014-05-30 15:21 ` Al Viro
2014-05-30 15:31 ` Linus Torvalds
2014-05-30 16:48 ` [git pull] " Al Viro
2014-05-30 17:14 ` Al Viro
2014-05-31 14:18 ` Josh Boyer
2014-05-31 14:48 ` Linus Torvalds
2014-05-31 14:58 ` Josh Boyer
2014-05-31 16:12 ` Josh Boyer
2014-05-30 17:15 ` Sedat Dilek
2014-05-29 4:21 ` Linus Torvalds
2014-05-29 5:16 ` Al Viro
2014-05-29 5:26 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140528183954.GA18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=mszeredi@suse.cz \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.