linux-kernel - Re: [PATCH 1/2] signals: collect_signal: remove the unneeded sigismember() check

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0805201903150.3081@woody.linux-foundation.org>
Date:	Tue, 20 May 2008 19:14:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Roland McGrath <roland@...hat.com>
cc:	Oleg Nesterov <oleg@...sign.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] signals: collect_signal: remove the unneeded
 sigismember() check

On Tue, 20 May 2008, Roland McGrath wrote:
> 
> drm_lock is using block_all_signals to catch all the stop signals
> for a purpose that is not immediately clear to me.  

It's basically the equivalent of a "spin_lock_irq()" for DRM, where 
signals are the "interrupts" that need to be blocked while holding the 
lock.

In order for the user-level direct-rendering code to be able to do a lock 
that is safe in the presense of signals, the locking code needs to have 
some way to basically disable signals. And it could disable/re-enable them 
all the time, but that would be very expensive and defeat the whole 
purpose (which is that you can get the lock cheaply in user space and only 
take a system call on a lock conflict).

So instead, when it gets the DRM lock, it also does that 
"block_all_signals()" thing, which means that *if* a signal happens, it 
can temporarily disable the signal so that the handler won't be invoced in 
the critical region.

Now, I have to admit that I do not know if the current user-level code 
needs that any more, and even if it does, if it could possibly be replaced 
by better models. It's a hack, no question about it. The whole DRI locking 
is something really odd. Don't even ask me how it's supposed to work.

			Linus
--
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/