Re: [PATCH 5/5] task_work: use TIF_NOTIFY_SIGNAL if available

[Thomas Gleixner <tglx@linutronix.de>]

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