linux-kernel - Re: processes hung after sys_renameat, and 'missing' processes

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]

Message-ID: <CA+55aFyp2GUbc218eb5BDyAqz+cOPTJMVcb4ptk+f1_RBB+-mg@mail.gmail.com>
Date:	Wed, 6 Jun 2012 17:42:35 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Jones <davej@...hat.com>, Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Miklos Szeredi <mszeredi@...e.cz>, Jan Kara <jack@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: processes hung after sys_renameat, and 'missing' processes

On Wed, Jun 6, 2012 at 5:29 PM, Dave Jones <davej@...hat.com> wrote:
>
> Like this ?

No.

>  void d_move(struct dentry *dentry, struct dentry *target)
>  {
>        write_seqlock(&rename_lock);
> +
> +       BUG_ON(!spin_is_locked(&target->d_parent->d_lock));
> +
> +       if (dentry->d_parent != NULL)
> +               BUG_ON(!spin_is_locked(&dentry->d_parent->d_lock));

It's true that the d_lock needs to be held too, but we actually do
that in __d_move() (which calls dentry_lock_for_move), so the callers
don't have to worry about that part.

So Al meant you to test mutex_is_locked(dentry->d_inode->i_mutex) of
the parents.

And I'd suggest making it just a WARN_ON_ONCE(), because if you make
it a BUG_ON() and it triggers, your system will likely be dead. And
ONCE is all that matters - it should never happen.

> To be clear, do you want me to try that with or without the reverts ?

I think either would be interesting. *If* that d_move() from
d_splice_alias ever triggers, that would be an interesting backtrace
to see too.

Of course, if that d_splice_alias change is the cause of this, then
with those two commits reverted you'd not be able to reproduce the
problem, which would also be interesting to know, so either way it
would be good information.

               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/