Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 21 Mar 2022 12:47:01 -0700 | Subject | Re: [GIT pull] core/core for v5.18-rc1 |
| |
On Mon, Mar 21, 2022 at 4:02 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > - Provide a mechanism to delay raising signals from atomic context on > PREEMPT_RT enabled kernels as sighand::lock cannot be acquired. Store > the information in the task struct and raise it in the exit path.
This isn't super-pretty, but doing it conditionally makes it even uglier.
I've pulled this, but my reaction to it all is "force_sig_info_to_task() isn't that critical, and CONFIG_RT_DELAYED_SIGNALS might as well have been unconditional".
In fact, is there any reason to make it conditional even at run-time, ie this:
> + if (!in_atomic()) > + return false;
looks a bit unnecessary too. Why not just always do that thing and avoid having two code-paths?
I really think we don't want more complexity in this unusual "force signal on exception" case, and TIF_NOTIFY_RESUME doesn't seem like it's the wrong place to do it.
Hmm?
Anyway, I've pulled it in this form, I just don't like the special cases that seem a bit pointless. They not only make the code bigger and more complex, they actively mean that test coverage is much worse too.
Linus
| |