Re: [PATCH 08/13] task_work: Call tracehook_notify_signal from get_signal on all architectures

[Kees Cook <keescook@chromium.org>]

On Thu, Mar 10, 2022 at 01:04:52PM -0600, Eric W. Biederman wrote:
> Kees Cook <keescook@chromium.org> writes:
> 
> > On Wed, Mar 09, 2022 at 10:24:49AM -0600, Eric W. Biederman wrote:
> >> Always handle TIF_NOTIFY_SIGNAL in get_signal.  With commit 35d0b389f3b2
> >> ("task_work: unconditionally run task_work from get_signal()") always
> >> calling task_wofffffffrk_run all of the work of tracehook_notify_signal is
> >
> > typo: cat on keyboard
> >
> >> already happening except clearing TIF_NOTIFY_SIGNAL.
> >> 
> >> Factor clear_notify_signal out of tracehook_notify_signal and use it in
> >> get_signal so that get_signal only needs one call of trask_work_run.
> >
> > typo: trask -> task
> >
> >> 
> >> To keep the semantics in sync update xfer_to_guest_mode_work (which
> >> does not call get_signal) to call tracehook_notify_signal if either
> >> _TIF_SIGPENDING or _TIF_NOTIFY_SIGNAL.
> 
> First let me say thanks for the close look at this work.
> 
> > I see three logical changes in this patch, I think?
> >
> > - creation and use of clear_notify_signal()
> > - removal of handle_signal_work() and removal of
> >   arch_do_signal_or_restart() has_signal arg
> > - something with get_signal() I don't understand yet:
> >   - why is clear_notify_signal() added?
> >   - why is tracehook_notify_signal() removed?
> 
> 
> The spoiler is the change to get_signal is the logical change.
> The rest of the changes follow from that change.  Please see below.
> 
> The inline expansion of tracehook_notify_signal in get_signal and
> in it's other two callers in the next change is the only real kernel
> internal api change in this series of changes.
> 
> The optimization that was tried with TIF_NOTIFY_SIGNAL and being able to
> only call task_work_run() when TIF_NOTIFY_SIGNAL was set instead of when
> get_signal was called failed, and caused a regression.  The removal of
> calling task_work_run from get_signal has been reverted but the rest
> of the change had not been.  So this change just removes the rest of
> the failed optimization.
> 
> Please see below for my detailed description of the get_signal change.
> 
> I hope this helps.

It does! Thanks very much for the additional details.

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook