[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YdUxGKRcSiDy8jGg@zeniv-ca.linux.org.uk>
Date: Wed, 5 Jan 2022 05:48:08 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alexey Gladkov <legion@...nel.org>,
Kyle Huey <me@...ehuey.com>, Oleg Nesterov <oleg@...hat.com>,
Kees Cook <keescook@...omium.org>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH 03/10] exit: Move oops specific logic from do_exit into
make_task_dead
On Wed, Dec 08, 2021 at 02:25:25PM -0600, Eric W. Biederman wrote:
> The beginning of do_exit has become cluttered and difficult to read as
> it is filled with checks to handle things that can only happen when
> the kernel is operating improperly.
>
> Now that we have a dedicated function for cleaning up a task when the
> kernel is operating improperly move the checks there.
Umm... I would probably take profile_task_exit() crap out before that
point.
1) the damn thing is dead - nothing registers notifiers there
2) blocking_notifier_call_chain() is not a nice thing to do on oops...
I'll post a patch ripping the dead parts of kernel/profile.c out tomorrow
morning (there's also profile_handoff_task(), equally useless these days
and complicating things for __put_task_struct()).
> - /*
> - * If do_exit is called because this processes oopsed, it's possible
> - * that get_fs() was left as KERNEL_DS, so reset it to USER_DS before
> - * continuing. Amongst other possible reasons, this is to prevent
> - * mm_release()->clear_child_tid() from writing to a user-controlled
> - * kernel address.
> - */
> - force_uaccess_begin();
Are you sure about that one? It shouldn't matter, but... it's a potential
change for do_exit() from a kernel thread. As it is, we have that
force_uaccess_begin() for exiting threads and for kernel ones it's not
a no-op. I'm not concerned about attempted userland access after that
point for those, obviously, but I'm not sure you won't step into something
subtle here.
I would prefer to split that particular change off into a separate commit...
Powered by blists - more mailing lists