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
| ||
|
Date: Tue, 13 Nov 2007 15:32:01 -0800 (PST) From: Roland McGrath <roland@...hat.com> To: Oleg Nesterov <oleg@...sign.ru> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] sigwait eats blocked default-ignore signals > But I suspect we have other issues here. Let's suppose we have threads T1 > (main) and T2. T2 blocks SIGCHLD and does sigwait(SIGCHLD). > > Now, we send SIGCHLD to the thread group. The signal is lost again because > sig_ignored() returns true on T1's side. > > Is this OK? [...] Yes, it's OK if T1 has SIGCHLD unblocked. When there are multiple threads that either don't block the signal or are in sigwait for it, then it can go to any of them and there are no guarantees at all about which. So we simply say that the signal went to the thread not in sigwait that has that signal unblocked (T1). When it got there, it was ignored. The user semantics are equivalent even if that thread never actually woke and dequeued the signal to ignore it. > I think __group_send_sig_info() shouldn't use sig_ignored() at > all. Instead, we should split __group_complete_signal() into 2 > functions. The first one, say, choose_target() shoud be used instead. The > second one, handle_fatal_signal() can also be used by tkill() and > friends. I will probably like any reorganization of the code that makes it cleaner. But we don't need to change the behavior in this regard. The most common path is __group_send_sig_info (from sys_kill), so it would be a shame to remove the short-circuit optimization there. In fact, it is probably wrong semantics to do so (for what applications expect, and possibly for POSIX conformance). That is, an unblocked, ignored (or default-ignore) signal should not set TIF_SIGPENDING and interrupt a system call in progress or just about to start. Obviously this is not a huge problem, since that's what happens under any debugger. But still, an undesireable change of semantics as well as de-optimization, I'd say. 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/
Powered by blists - more mailing lists