Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Dec 2018 20:47:59 +0100
From: Markus Wichmann <>
Subject: Re: sem_wait and EINTR

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]
> [2]
> [3]

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.

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!


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.