linux-kernel - Re: What does drm do with signals?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070825110139.GA234@tv-sign.ru>
Date:	Sat, 25 Aug 2007 15:01:39 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Dave Airlie <airlied@...il.com>
Cc:	Dave Airlie <airlied@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: What does drm do with signals?

On 08/25, Dave Airlie wrote:
>
> On 8/24/07, Oleg Nesterov <oleg@...sign.ru> wrote:
> > Could someone please explain why do we need block_all_signals() ?
> >
> > I can't understand what was the intended behaviour, but anyway
> > I suspect it doesn't work as expected.
> 
> http://dri.sourceforge.net/doc/drm_low_level.html
> 
> Section 4.1 explains the intent...

Thanks a lot Dave, I'll quote this doc:

> 4.1 Delaying Signal Delivery
>
>  If the direct-rendering client holds the hardware lock and receives
>  a SIGKILL signal, deadlock may result. If the SIGKILL is detected
>  and the hardware lock is immediately taken from the client, the
>  typical PC-class graphics hardware may be left in an unknown state
>  and may lock up (this kind of hardware usually does not deal well
>  with intermingling of command streams).
>
>  Similarly, if the direct-rendering client holds the hardware lock
>  and receives a SIGSTOP, the X server and all other direct-rendering
>  clients will block until the process releases the lock.
>
>  Ideally, the client should be permitted to complete the rendering
>  operation that is currently in progress and have the SIGKILL or SIGSTOP
>  signals delivered as soon as the hardware lock is released (or, after
>  some reasonable timeout, so that buggy clients can be halted). This
>  delay of signal delivery appears to require kernel-level changes
>  that cannot be performed by a loadable module using the standard
>  module interface.

but drm_lock() doesn't even try to block SIGKILL?

However, I think that block_all_signals() and its usage are broken
in many ways. To name a few,

1. It can't work for multithread programs. dequeue_signal() checks
   current->notifier, but this is per thread, not per process.

2. We can't block the "pseudo signals" (freezer).

3. If we want to block SIGKILL, we should also block at least all
   sig_kernel_coredump() signals. But this is not easy to do for
   multithread programms, all sub-threads except ->group_exit_task
   go to sleep in TASK_STOPPED state without doing dequeue_signal()
   at all.

4. What about other sig_fatal() signals?

5. drm_lock() blocks SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU. Suppose
   that (say) SIGTSTP is pending. In that case we in fact block
   _all_ signals whose numeric value > SIGTSTP. This is somewhat
   strange.

Probably something else... Actually, the whole idea looks broken to
me, but yes, it is very easy to blame somebody else's code and I
don't even remotely understand what drm is.

I tried to google for the patch which introduced this interface
but failed. Looks like this is very old thing.

Actually, I can't understand the explanation above. What if the
task which holds the hardware lock doesn't recieve SIGSTOP, but
instead does something like "for (;;) ;" ?

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/