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

[Samuel Thibault <samuel dot thibault at ens-lyon dot org>]

Hello,

Roland McGrath, le Wed 07 Jan 2009 18:10:19 -0800, a écrit :
> It also should start its critical section before the first lookup.

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?

dirfd and _hurd_fd_opendir (and thus __opendir and __fdopendir) also
take locks, I guess these should get critical sections as well.

> And I think the unlock/relock case has a lock order problem in case
> of other threads that hold _hurd_dtable_lock while getting an fd spin lock.

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.

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?

Samuel