Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Sep 2014 23:31:13 +0100
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: Add login_tty

On Thu, Sep 4, 2014 at 10:33 PM, Rich Felker <dalias@...c.org> wrote:
> Actually, musl's dup2 already accounts for the issue by looping
> internally, but I'm thinking we should remove that. POSIX does not
> forbid dup2 from failing when you do something idiotic like this
> (actually, like I said, I think it's morally UB), but it does demand
> that open and dup2 be atomic with respect to each other for regular
> files, whereas the loop would delay indefinitely a thread calling dup2
> on a file descriptor for which another thread is stuck in
> uninterruptible sleep trying to open (e.g. slow/dead NFS).
>
> Any thoughts on whether/how this should be changed?

Both FreeBSD and NetBSD block indefinitely on dup2 running the example
code, and this behaviour does not seem wholly unreasonable. But
removing the loop in Musl seems right, and having a note in the man
page saying if you get EBUSY you did something stupid, so abort on
this seems best.

Justin

Powered by blists - more mailing lists

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