linux-kernel - Re: fs: uninterruptible hang in handle

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: <20160302004845.GF17997@ZenIV.linux.org.uk>
Date:	Wed, 2 Mar 2016 00:48:46 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dmitry Vyukov <dvyukov@...gle.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: fs: uninterruptible hang in handle_userfault

On Tue, Mar 01, 2016 at 12:06:49PM -0800, Linus Torvalds wrote:

> So the only access we really care about is the child tid-pointer
> clearing one, and that always happens after PF_EXITING has been set
> afaik.
> 
> No other case really matters. If somebody accesses a userfault region
> just as another thread is exiting, we don't care. I don't think it
> would necessarily be wrong to ignore the fault, but I don't think it's
> relevant either, since at that stage the normal "you can signal the
> thread" still works. It's only the child tid access that comes *after*
> we have stopped acceping signals, and that's marked by that
> PF_EXITING.
> 
> Or maybe I misunderstood your worry entirely or missed something, and
> my answer above is entirely beside your point. Did you have something
> else in mind?

No, I've misread de_thread()/zap_other_threads().  No objections to the
patch.