linux-kernel - Re: SIGNAL_STOP

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]

Date:	Sat,  1 Sep 2007 00:12:26 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: SIGNAL_STOP_DEQUEUED

> Yes. do_wait(WCONTINUED) can miss SIGNAL_STOP_CONTINUED task if the task
> dequeues another sig_kernel_stop() signal. I thought this is harmless, but
> it turns out I misunderstood the needed semantics.
> 
> Thanks for your explanation.
> 
> This is easy to fix, but we have to split SIGNAL_STOP_CONTINUED into 2 flags,
> one for do_wait(), another to indicate that do_signal_stop() should abort.

SIGNAL_STOP_DEQUEUED is that second flag (its lack says to abort the stop).

> However, is it all correct currently ? Consider 2 threads, T1 and T2,
> SIGTTIN is SIG_DFL, SIGTTOU has a handler.
> 
> 	T1 does get_signal_to_deliver(), dequeus SIGTTIN, unlocks ->siglock.
> 
> 	SIGCONT comes in, nothing to do yet, just clear SIGNAL_STOP_DEQUEUED.
> 
> 	SIGTTOU is sent, T2 dequeues it and sets SIGNAL_STOP_DEQUEUED again.
> 	It has a handler, we shouldn't stop, but
> 
> 	T1 continues, takes ->siglock, and calls do_signal_stop().

Yes, I think you are right that this could happen.  It is indeed wrong that
it's possible to stop with SIGTTIN when the SIGCONT was posted second.

> What do you think about something like the patch below? It moves the setting of
> SIGNAL_STOP_DEQUEUED from dequeue_signal() to get_signal_to_deliver(), and the
> flag is set only if the sig_kernel_stop() signal doesn't have a handler.

I don't recall why this went into dequeue_signal in the first place.  It's
possible there was a specific reason at the time, but I can't find one now.
Probably it just seemed natural at the time to set the flag very close the
actual dequeuing just so it's simple to be sure what the invariant is.


Thanks,
Roland
-
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/