On Sun, 27 Aug 2000, Alexander Viro wrote:
> On Sun, 27 Aug 2000 kuznet@ms2.inr.ac.ru wrote:
>
> > > Subtle, britlle and nonportable.
> >
> > It is nonportable _only_ to Linux (and to old freebsds btw,
> > its user level pthread library had the same bug).
>
> Huh?
> <doing cvs update just in case>
> <reading sys_generic.c::read() and sys_generic.c::dofileread()>
>
> Nope, world didn't change - read(9) does getfp(9) [== our fget(9)] and
> then calls dofileread(9). The former returns the same on all dup()-created
> copies of descriptor, the latter doesn't use fd at all unless you build
> with KTRACE. Even if you do, the call that might, in principle, depend on
> fd is done after fo_read(9).
>
> _If_ somebody had changed FreeBSD so that close() on dup()'d descriptor
> aborts read() on the original - he needs severe LARTing. I'm not on a
> -CURRENT box right now, so I can't check it immediately, but you bet that
> if it really does that idiocy it's going to be a send-pr time. Big way.
> And AFAICS the idiocy above is the only way it can do what you've
> described - it doesn't distinguish the dup()'d descriptors until the very
> end of operation, way past any waiting for incoming data.
PS: after checking uipc_syscall.c it looks like they can't distinguish
between the different dup()'d copies for recvfrom() too - not until the
->pru_soreceive() returns.
And that's -CURRENT, so I really wonder whether the thing is done in the
kernel at all - I don't think that they went for such a violation of
normal UNIX semantics. close(dup(fd)) should have _no_ effect. POSIX locks
violate that rule, but that's one of the best reasons to avoid them like a
plague. Breaking it for read(2)... <shudder>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST