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.
