lkml.org 
[lkml]   [2021]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 08, 2021 at 09:26:40AM -0700, Jens Axboe wrote:
> >> Can you show the callers that DO NOT need it?
> >
> > OK, so here's my suggestion:
> >
> > 1) For 5.11, we just re-instate the task_work run in get_signal(). This
> > will make TWA_RESUME have the exact same behavior as before.
> >
> > 2) For 5.12, I'll prepare a patch that collapses TWA_RESUME and TWA_SIGNAL,
> > turning it into a bool again (notify or no notify).
> >
> > How does that sound?
>
> Attached the patches - #1 is proposed for 5.11 to fix the current issue,
> and then 2-4 can get queued for 5.12 to totally remove the difference
> between TWA_RESUME and TWA_SIGNAL.
>
> Totally untested, but pretty straight forward.

Umm... I'm looking at the callers of get_signal() and I really wonder
how your support for TIF_NOTIFY_SIGNAL interacts with saved sigmask handling
by various do_signal() (calls of restore_saved_sigmask()). Could you give
pointers to relevant discussion or a braindump on the same? I realize that
it had been months ago, but...

Do we even need restore_saved_sigmask_unless() now? Could
set_user_sigmask() simply set TIF_NOTIFY_SIGNAL? Oleg, could you comment
on that?

Another fun question is how does that thing interact with
single-stepping logics; it's been about 8 years since I looked into
those horrors, but they used to be bloody awful...

What I'm trying to figure out is how costly TIF_NOTIFY_SIGNAL is
on the work execution side; task_work_add() side is cheap enough, it's
delivery that is interesting.

\
 
 \ /
  Last update: 2021-01-08 19:08    [W:0.052 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site