From owner-freebsd-hackers@freebsd.org Thu Dec 13 20:11:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EB7A1332EE9 for ; Thu, 13 Dec 2018 20:11:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79924702E7; Thu, 13 Dec 2018 20:11:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wBDKBh1M027920 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Dec 2018 22:11:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wBDKBh1M027920 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wBDKBgIL027919; Thu, 13 Dec 2018 22:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Dec 2018 22:11:42 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: andrew@ziglang.org, "freebsd-hackers@freebsd.org" Subject: Re: raise() implementation in freebsd libc vs musl libc Message-ID: <20181213201142.GP60291@kib.kiev.ua> References: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 20:11:52 -0000 On Wed, Dec 12, 2018 at 10:00:56PM -0800, Conrad Meyer wrote: > Hi Andrew, > > The musl signal blocking dates to this commit: > > https://git.musl-libc.org/cgit/musl/commit/?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9 > > The concern raised in that commit was that raise(3) could > theoretically be interrupted by a concurrently running signal handler > which invokes fork() (also sighandler-safe), resulting in > inconsistent/stale values from gettid(2)/getpid(2) on Linux (at the > time). But even then, for the child to signal wrong thread, it must return from the signal frame to the interrupted frame executing raise(). This would be really weird design. > > On both systems, gettid(2) / thr_self(2) returns a unique thread > identifier that cannot be reused until the thread it identifies has > exited. So, I don't know. I guess if fork happens between thr_self() > and thr_kill(), the parent process may have already exited and had its > tid recycled by the time the child process invokes thr_kill(). The difference between Linux and FreeBSD there, as I see it, is that thr_kill() only allows to send signals to the threads in the current process. So when the forked child sends a signal to the thread identified by the parent' thread id, nothing happens except an error code returned. > > OTOH, that seems like a pretty byzantine / broken application? I'm > not sure it's libc's job to prevent applications from shooting > themselves in the foot. Forking in a signal handler is already > somewhat dicey, and especially so if the child does not immediately > exec() or _exit(2). Forking in a signal handler is fine, assuming that the signal handler only uses async-signal safe functions, regardless of exec/_exit. Problem there is that atfork handlers must only use async-safe functions, which means that the author of the signal handler must be aware of the whole application code, including all libraries. > > Anyway, that's just my guess. I am not a libthr expert on either BSD > nor Linux, so take this with a big grain of salt. Signals were a > mistake ;-). > > Best, > Conrad > > P.S., Zig looks quite promising, I am excited to see where it goes. > > > On Wed, Dec 12, 2018 at 9:12 PM Andrew Kelley wrote: > > > > Howdy, > > > > I noticed that musl-libc blocks signals in raise() to prevent a race > > condition, but freebsd libc does not. is there a reason it's necessary > > on linux and not freebsd? > > > > musl > > int raise(int sig) > > { > > sigset_t set; > > __block_app_sigs(&set); > > int ret = syscall(SYS_tkill, __pthread_self()->tid, sig); > > __restore_sigs(&set); > > return ret; > > } > > > > freebsd > > int > > __raise(int s) > > { > > long id; > > > > if (__sys_thr_self(&id) == -1) > > return (-1); > > return (__sys_thr_kill(id, s)); > > } > > > > Regards, > > Andrew > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"