[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160301195957.GD17997@ZenIV.linux.org.uk>
Date: Tue, 1 Mar 2016 19:59:58 +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 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?
Powered by blists - more mailing lists