lkml.org 
[lkml]   [2022]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2022-03-21 20:49    [W:0.066 / U:2.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site