From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13502 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sem_wait and EINTR Date: Wed, 5 Dec 2018 16:58:26 -0500 Message-ID: <20181205215826.GX23599@brightrain.aerifal.cx> References: <20181205191605.72492698@orivej.orivej.org> <20181205194759.GA32233@voyager> <20181205212716.sx6ra2xqhuei735q@core.my.home> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1544046995 28146 195.159.176.226 (5 Dec 2018 21:56:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2018 21:56:35 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13518-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 05 22:56:31 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gUf9i-0007Br-Th for gllmg-musl@m.gmane.org; Wed, 05 Dec 2018 22:56:30 +0100 Original-Received: (qmail 12215 invoked by uid 550); 5 Dec 2018 21:58:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12194 invoked from network); 5 Dec 2018 21:58:39 -0000 Content-Disposition: inline In-Reply-To: <20181205212716.sx6ra2xqhuei735q@core.my.home> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13502 Archived-At: On Wed, Dec 05, 2018 at 10:27:16PM +0100, Ondřej Jirman wrote: > On Wed, Dec 05, 2018 at 08:47:59PM +0100, Markus Wichmann wrote: > > On Wed, Dec 05, 2018 at 07:16:05PM +0000, Orivej Desh wrote: > > > Hi, > > > > > > musl differs from glibc in that it does not return from sem_wait() on EINTR. > > > This mail [1] explains that this is useful to safeguard the software that does > > > not check sem_wait() return code. However, since glibc does return EINTR, such > > > bugs in the open source software seem to be eventually noticed and fixed. > > > > > > The musl behaviour has a disadvantage in that it makes sem_wait() difficult to > > > interrupt (and delays the return from sem_timedwait() until the timeout), which > > > is relied upon in particular by multithreaded fuse for breaking out of the > > > main thread waiting loop [2]. IMHO the fuse implementation is sensible, since it > > > looks better than the alternatives I could imagine, and I'm inclined to patch > > > musl like this [3] to meet its expectations. > > > > > > Am I missing some implications? Would you reconsider returning from sem_wait() > > > on EINTR? Could you suggest a good fix for fuse that does not change musl? > > > > > > [1] https://www.openwall.com/lists/musl/2018/02/24/3 > > > [2] https://github.com/libfuse/libfuse/blob/fuse-3.3.0/lib/fuse_loop_mt.c#L332 > > > [3] https://github.com/orivej/musl/commit/c4c38aaab4fc55c23669f7b81386b615609cc3e1 > > > > I wanted to suggest a reworking of libfuse to instead of waiting on a > > semaphore maybe just wait on the actual thread. Then I read the source > > of pthread_join() and noticed that it, too, would hang itself in a loop > > it can't break out of due to EINTR. > > > > Maybe the simplest solution would be to simply tell libfuse users to > > call fuse_session_exit() from the SIGINT handler if they want this > > behavior to be portable. If fuse_session_exit() is not > > async-signal-safe, then handle SIGINT in another thread using > > pthread_sigmask() and sigwaitinfo(). > > > > In any case, libfuse is relying on behavior not guarenteed by the > > interface. The fact that a certain implementation of the interface > > happens to provide that behavior is irrelevant. > > Hello, > > It's specified by POSIX: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_wait.html > > Sates: "The sem_wait() function is interruptible by the delivery of a signal." This seems contradictory with EINTR being a "may fail" error, and, if interpreted the way you want to interpret it, seems to be contradictory with SA_RESTART semantics, since it doesn't say anything about whether that signal is an interrupting one. I think we should attempt to obtain a clarification on what the intent is here. Does "is interruptible" mean that it needs to fail on signals (only without SA_RESTART?) or simply that signal handlers must be permitted to run (i.e. the wait can't happen with signals blocked)? > > On a practical note, I certainly never expected sem_wait() to be capable > > of failing due to errors other than bad programming before. Coding that > > in would make even simple things like the consumer-producer example by > > Dijkstra look horrible! > > There's a difference between pedagogy and production code. > > Just wanted to share that I was bitten myself by blindly retrying on EINTR instead > of handling it correctly for the particular program. > > For example: When using signalfd, it is critical to be handling EINTR correctly > by getting back to the main loop so that signal handler can be executed (as it > is not executed asynchronously). I certainly would not expect the C library to be > eating EINTRs. Most attempts to use EINTR (any without backoff-and-resignal) are subject to race conditions, so it's hard to expect that you can do thing kind of thing safely. Also, the state of stdio FILEs after EINTR does not seem to be predictable/recoverable. With that said, it is my intent to implement the specified requirements as best we can, even if I disagree over whether they're useful. So let's see if we can get answers on what's supposed to happen. Rich