Jens,
On Fri, Oct 16 2020 at 07:33, Jens Axboe wrote:
> On 10/16/20 3:00 AM, Thomas Gleixner wrote:
> I totally agree, and we're on the same page. I think you'll find that in
> the past I always carry through, the task_work notification was somewhat
> of a rush due to a hang related to it. For this particular case, the
> cleanups and arch additions are pretty much ready to go.
As we seem to be on the same page with this, let me suggest how this
should go:
1) A cleanup for the task_work_add() mess. This is trivial enough and
should go in before rc1.
2) The TIF_NOTIFY_RESUME change is a nice cleanup on it's own and can go
before rc1 as well.
This gets stuff out of the way and reduces conflict surface.
3) Core infrastructure (patch 2 + 3 + 5) of this series
Please make the changes I asked for in the generic entry code and
moving the handling into get_signal() for everybody else.
So get_signal() gains:
if (!IS_ENABLED(CONFIG_GENERIC_ENTRY) {
(test_thread_flag(TIF_NOTIFY_SIGNAL))
tracehook_notify_signal();
if (!task_sigpending(current))
return 0;
}
And with that you don't have to touch do_signal() in any architecture
except x86 which becomes:
arch_do_signal_or_restart(bool sigpending)
4) Conversion of all architectures which means adding the TIF bit.
If the architecture folks are happy, then this can be collected in
tip, which would be preferred because then
5) Cleanups
can just go on top.
Hmm?
Thanks,
tglx
