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: <CA+55aFzakVoCmAptYdCpEEgK9z003Qk-e_RCC-Gc8Tqt3L8+Cw@mail.gmail.com>
Date:	Tue, 1 Mar 2016 12:06:49 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
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 1, 2016 at 11:59 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Tue, Mar 01, 2016 at 11:56:22AM -0800, Linus Torvalds wrote:
>> (a) special-case the PF_EXITING case for usefaultfd, something like
>>
>>     diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
>>     index 50311703135b..66cdb44616d5 100644
>>     --- a/fs/userfaultfd.c
>>     +++ b/fs/userfaultfd.c
>>     @@ -287,6 +287,12 @@ int handle_userfault(struct vm_area_struct
>> *vma, unsigned long address,
>>                     goto out;
>>
>>             /*
>>     +        * We don't do userfault handling for the final child pid update.
>>     +        */
>>     +       if (current->flags & PF_EXITING)
>>     +               goto out;
>
> Umm...  Probably a dumb question, but would that suffice when e.g. another
> thread is just starting to dump core?

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?

                 Linus