[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63222e71-d2a5-47d6-a5cb-4c822441f448@kernel.dk>
Date: Wed, 9 Mar 2022 14:05:08 -0700
From: Jens Axboe <axboe@...nel.dk>
To: "Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org
Cc: 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>,
Al Viro <viro@...IV.linux.org.uk>, linux-api@...r.kernel.org
Subject: Re: [PATCH 00/13] Removing tracehook.h
On 3/8/22 5:13 PM, Eric W. Biederman wrote:
>
> While working on cleaning up do_exit I have been having to deal with the
> code in tracehook.h. Unfortunately the code in tracehook.h does not
> make sense as organized.
>
> This set of changes reorganizes things so that tracehook.h no longer
> exists, and so that it's current contents are organized in a fashion
> that is a little easier to understand.
>
> The biggest change is that I lean into the fact that get_signal
> always calls task_work_run and removes the logic that tried to
> be smart and decouple task_work_run and get_signal as it has proven
> to not be effective.
>
> This is a conservative change and I am not changing the how things
> like signal_pending operate (although it is probably justified).
>
> A new header resume_user_mode.h is added to hold resume_user_mode_work
> which was previously known as tracehook_notify_resume.
This is a nice cleanup. I did bother me adding the TIF_NOTIFY_SIGNAL
bits and work hooks to something unrelated, but that's where other
things resided then. This makes it a lot better.
--
Jens Axboe
Powered by blists - more mailing lists