From: Christoph Böhmwalder
> Sent: 05 August 2019 10:33
>
> On 29.07.19 10:50, David Laight wrote:
> > Doesn't unmasking the signals and using send_sig() instead of force_sig()
> > have the (probably unwanted) side effect of allowing userspace to send
> > the signal?
>
> I have ran some tests, and it does look like it is now possible to send
> signals to the DRBD kthread from userspace. However, ...
>
> > I've certainly got some driver code that uses force_sig() on a kthread
> > that it doesn't (ever) want userspace to signal.
>
> ... we don't feel that it is absolutely necessary for userspace to be
> unable to send a signal to our kthreads. This is because the DRBD thread
> independently checks its own state, and (for example) only exits as a
> result of a signal if its thread state was already "EXITING" to begin
> with.
In must 'clear' the signal - otherwise it won't block again.
I've also got this horrid code fragment:
init_waitqueue_entry(&w, current);
/* Tell scheduler we are going to sleep... */
if (signal_pending(current) && !interruptible)
/* We don't want waking immediately (again) */
sleep_state = TASK_UNINTERRUPTIBLE;
else
sleep_state = TASK_INTERRUPTIBLE;
set_current_state(sleep_state);
/* Connect to condition variable ... */
add_wait_queue(cvp, &w);
mutex_unlock(mtxp); /* Release mutex */
where we want to sleep TASK_UNINTERRUPTIBLE but that f*cks up the 'load average',
so sleep TASK_INTERRUPTIBLE unless there is a signal pending that we want to
ignore.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
