Re: [PATCH] thread wakeup fix for 2.4.0-test7

From: Alexander Viro (
Date: Mon Aug 28 2000 - 13:51:15 EST

On Mon, 28 Aug 2000 wrote:

> Hello!
> > _not_ aborting read() and in absence of the third thread we _do_ abort
> > read(). QED: close(dup(fd1)) changes the behaviour of program.
> >
> > IIRC, you've agreed that it was wrong just a couple of posts upthread.
> Read is aborted as soon as file closed. File is closed,

read() may succeed _before_ you close the dup()'d descriptor. You are
thinking about the case when the thing is never going to receive anything
_and_ kernel has no way to recognize that, right? (otherwise kernel should
just return 0 and be done with that). Now, look at the case where read()
_will_ eventually succeed (since we are in "no way to tell" area, we can't
exclude all these cases, right?) Look at the scenario above for that case.
You've got close(dup()) racing with read() and close(); in some cases you
get -EBADF, in some - data. And that race is going to be a hell to hunt

Yes, programs may need a way to abort blocked IO. But overloading close()
is a *very* bad idea.

> Moreover! If read() has some _data_ read while close() (due to race or
> due to SO_RCVLOWAT) it does not return error. It returns data
> despite of neither descriptor nor file itself exist to this time.
> It is normal.

See above.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:22 EST