Re: [PATCH,HURD] Fix __dup2 _hurd_dtable_lock usage.

[Roland McGrath <roland at redhat dot com>]

> Oh, you mean because _hurd_fd_get() takes locks?  There are quite a few
> other places where that happens too (e.g. __opendir, __libc_fcntl, ...),
> maybe we should rather make _hurd_fd_get have its own critical section?

Actually I was thinking there was an issue with the pointer it returns.
But there isn't, those are never freed once allocated.  That it takes locks
is an issue too, but like you say that issue is all over.

> Mmm, I don't see how.  Actually I don't understand the "We still hold
> FD1's lock" comment, which lock is it talking about? d->ctty is not
> locked and d->port got unlocked before taking the dtable mutex.  And
> later, when we re-take the dtable mutex, d2 is unlocked.

You're right.  It was that comment that made me think there was a problem.
But the comment is wrong and the unlock+relock sequence is fine.

> Also it seems to me that we can release the dtable mutex earlier, right
> after the if (fd2 >= _hurd_dtablesize) { } else { } statement, don't we?

I think so, yes.


Thanks,
Roland