From: Jens Axboe <[email protected]>
To: Thomas Gleixner <[email protected]>, Oleg Nesterov <[email protected]>
Cc: [email protected], [email protected],
[email protected], Roman Gershman <[email protected]>
Subject: Re: [PATCH 5/5] task_work: use TIF_NOTIFY_SIGNAL if available
Date: Fri, 16 Oct 2020 08:22:58 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 10/16/20 8:11 AM, Thomas Gleixner wrote:
> 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.
No problem, I'll get that posted shortly.
> 2) The TIF_NOTIFY_RESUME change is a nice cleanup on it's own and can go
> before rc1 as well.
Would you mind taking that one? It's good to go.
> 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)
Already did most of this, just need to handle the !CONFIG_GENERIC_ENTRY
for get_signal() and adapt the existing non-generic arch patches to
this.
> 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
Mostly done,
>
> 5) Cleanups
>
> can just go on top.
>
> Hmm?
Sounds good to me, as long as we keep the existing ordering with
x86/generic TIF_NOTIFY_SIGNAL support being able to move forward
before all archs have acked the arch specific change. Doesn't really
change how I'll get it done, and we're mostly there. Just don't
anything gated on potential slowest common denominator.
--
Jens Axboe
prev parent reply other threads:[~2020-10-16 14:23 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 13:16 [PATCHSET v5] Add support for TIF_NOTIFY_SIGNAL Jens Axboe
2020-10-15 13:16 ` [PATCH 1/5] tracehook: clear TIF_NOTIFY_RESUME in tracehook_notify_resume() Jens Axboe
2020-10-15 14:42 ` Oleg Nesterov
2020-10-15 14:43 ` Jens Axboe
2020-10-15 13:16 ` [PATCH 2/5] kernel: add task_sigpending() helper Jens Axboe
2020-10-15 14:42 ` Oleg Nesterov
2020-10-15 13:16 ` [PATCH 3/5] kernel: add support for TIF_NOTIFY_SIGNAL Jens Axboe
2020-10-15 14:31 ` Oleg Nesterov
2020-10-15 14:33 ` Jens Axboe
2020-10-15 14:37 ` Oleg Nesterov
2020-10-15 14:43 ` Jens Axboe
2020-10-15 14:47 ` Oleg Nesterov
2020-10-15 14:53 ` Oleg Nesterov
2020-10-15 14:56 ` Jens Axboe
2020-10-15 15:01 ` Thomas Gleixner
2020-10-15 15:27 ` Oleg Nesterov
2020-10-15 14:44 ` Oleg Nesterov
2020-10-15 13:17 ` [PATCH 4/5] x86: wire up TIF_NOTIFY_SIGNAL Jens Axboe
2020-10-15 14:11 ` Thomas Gleixner
2020-10-15 14:31 ` Jens Axboe
2020-10-15 14:34 ` Thomas Gleixner
2020-10-15 14:35 ` Jens Axboe
2020-10-15 14:36 ` Oleg Nesterov
2020-10-15 14:42 ` Jens Axboe
2020-10-15 14:34 ` Oleg Nesterov
2020-10-15 14:54 ` Thomas Gleixner
2020-10-15 15:17 ` Oleg Nesterov
2020-10-16 9:55 ` Thomas Gleixner
2020-10-16 10:54 ` Oleg Nesterov
2020-10-16 13:07 ` Thomas Gleixner
2020-10-15 14:44 ` Oleg Nesterov
2020-10-20 10:57 ` introduce asm-generic/thread_info.h ? Oleg Nesterov
2020-10-15 13:17 ` [PATCH 5/5] task_work: use TIF_NOTIFY_SIGNAL if available Jens Axboe
2020-10-15 15:49 ` Oleg Nesterov
2020-10-15 18:39 ` Jens Axboe
2020-10-16 9:00 ` Thomas Gleixner
2020-10-16 9:39 ` Thomas Gleixner
2020-10-16 13:35 ` Jens Axboe
2020-10-16 14:17 ` Thomas Gleixner
2020-10-16 14:51 ` Oleg Nesterov
2020-10-16 14:53 ` Jens Axboe
2020-10-16 18:03 ` Thomas Gleixner
2020-10-16 18:05 ` Jens Axboe
2020-10-16 13:33 ` Jens Axboe
2020-10-16 14:11 ` Thomas Gleixner
2020-10-16 14:22 ` Jens Axboe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox