block_all_signals() usage in DRM

On 05/25, Richard Weinberger wrote: > > Is this functionality still in use/needed? All I can say it doesn't work. > Otherwise we could get rid of block_all_signals() and unpuzzle the signaling > code a bit. :-) Yes. I do not even remember when I reported this the first time. Perhaps more tha

block_all_signals() must die (Was: Patch for lost wakeups)

And sorry for off-topic email, but I can't resist. Can't we finally kill block_all_signals() and ->notifier ? This is very, very wrong and doesn't work anyway. I tried to ask many, many times. Starting from 2007 at least. And every time the discussion "hangs". I am quoting the last email I sent b

[PATCH 1/1] signals: kill block_all_signals() and unblock_all_signals()

er is single-threaded, it will "stop" anyway. It will not sleep, but it will spin in kernel space until SIGCONT or SIGKILL. And a lot more. In short, this interface doesn't work at all, at least the last 10+ years. Signed-off-by: Oleg Nesterov --- drivers/gpu/d

[PATCH 0/1] signals: kill block_all_signals() and unblock_all_signals()

On 05/26, Dave Airlie wrote: > > On 26 May 2015 at 02:50, Oleg Nesterov wrote: > > On 05/25, Richard Weinberger wrote: > >> > >> Is this functionality still in use/needed? > > > > All I can say it doesn't work. > > > >> Othe

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24, Daniel Vetter wrote: > > wait_event_killabel doesn't check for fatal_signal_pending before calling > schedule, so definitely has a nice race there. This is fine. See the signal_pending_state() check in __schedule(). And this doesn't differ from wait_event_interruptible(), it too doesn't

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25, Daniel Vetter wrote: > > On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote: > > On 04/24, Daniel Vetter wrote: > >> > >> wait_event_killabel doesn't check for fatal_signal_pending before calling > >> schedule, so definitely has a ni

drm_lock()->block_all_signals() is broken

Hello. I tried many times to ask about the supposed behaviour of block_all_signals() in drm, but it seems nobody can answer. So I am going to send the patch which simply removes block_all_signals() and friends. There are numeruous problems with this interace, I can't even enumerate them. But I th

Re: drm_lock()->block_all_signals() is broken

On 07/12, Dave Airlie wrote: > > On Tue, Jul 12, 2011 at 7:15 PM, Oleg Nesterov wrote: > > Hello. > > > > I tried many times to ask about the supposed behaviour of > > block_all_signals() in drm, but it seems nobody can answer. > > Its not hard to explain, basi

drm_lock()->block_all_signals() is broken

Hello. I tried many times to ask about the supposed behaviour of block_all_signals() in drm, but it seems nobody can answer. So I am going to send the patch which simply removes block_all_signals() and friends. There are numeruous problems with this interace, I can't even enumerate them. But I th

drm_lock()->block_all_signals() is broken

On 07/12, Dave Airlie wrote: > > On Tue, Jul 12, 2011 at 7:15 PM, Oleg Nesterov wrote: > > Hello. > > > > I tried many times to ask about the supposed behaviour of > > block_all_signals() in drm, but it seems nobody can answer. > > Its not hard to explain, basi

block_all_signals() must die (Was: Patch for lost wakeups)

And sorry for off-topic email, but I can't resist. Can't we finally kill block_all_signals() and ->notifier ? This is very, very wrong and doesn't work anyway. I tried to ask many, many times. Starting from 2007 at least. And every time the discussion "hangs". I am quoting the last email I sent b

[PATCH 1/1] signals: kill block_all_signals() and unblock_all_signals()

ping ;) Andrew, should I re-send this patch? It was acked by Daniel and Dave doesn't object. Dave, I'll appreciate it if you ack it explicitly. On 08/27, Oleg Nesterov wrote: > > It is hardly possible to enumerate all problems with block_all_signals() > and unblock_all_