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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 May 2014 14:11:51 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Miklos Szeredi <mszeredi@...e.cz>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

On Wed, May 28, 2014 at 1:14 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Unless I'm badly misreading your patch, you are calling dentry_kill()
> with rcu_read_lock() held.  And that can trigger all sorts of interesting
> things, starting with iput() and tons of disk IO...

Yes, right you are.

As to my worry:

> d_walk() covers its arse with ->d_lock (and it wants the starting point
> to be pinned, obviously).  So AFAICS RCU is not a problem.

It's not RCU itself, it's that DCACHE_MAY_FREE bit. Yes, d_walk() gets
->d_lock, but dentry_kill() drops d_lock in the middle, and the whole
"dentry_kill() can get called multiple times for the same dentry" just
makes me go "Hmm". It is *not* obvious what happens the second vs
third time that gets called. If it can get called two times, why not
three times? And if it can get called three times, why can't _two_ of
them set "can_free" to true? That is absolutely *not* obvious to me.

The aim of my patch (and I agree that sadly holding the rcu lock is
not viable) was to make that "if it gets called twice" case _much_
more obvious. Because any but the first time will be very obviously a
no-op (apart from taking and releasing the lock, which is ok for a
rcu-delayed data structure). That's very much not the case with
DCACHE_MAY_FREE. The behavior of that things os very much non-obvious,
because different callers into dentry_kill() all do different things.

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