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

From: Alexander Viro (viro@math.psu.edu)
Date: Mon Aug 28 2000 - 12:10:06 EST


On Mon, 28 Aug 2000 kuznet@ms2.inr.ac.ru wrote:

> > > > Yes? So how about
> > > > fd2 = dup(fd1);
> > > > read(fd1,...);
> > > > close(fd1);
> > So _which_ case should abort read()?
>
> No case. f_users is not zero, nothing happens.

In other words, with three threads we have

read(fd1...) fd2=dup(fd1);
                        close(fd1);
...
[here read() would succeed]
...
                                                close(fd2);
_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.

> What happens now is race window: if close(fd) happens before
> read(fd) grabbed fd or after it fput() it, we get EBADF,
> otherwise read() hangs forever. (Actually, even absence of invariance
> can be considered as bug.)

Yes? How about close() right _after_ read() returns? Should it
retroactively change the return value to -EBADF? You have the race
anyway.

Look: you are asking for completely new mechanism for aborting blocked
IO operations. Occam's Razor applies.

Arguments against that mechanism:
        * doesn't work unless caller has all references to file at hands
and remembers about them.
        * doesn't provide anything new compared to kill(2).
        * in the case when read would succeed it introduces a new effect -
close(dup(fd)) changes the program behaviour.

What are your arguments for the inclusion of this mechanism, aside of the
fact that Solaris has it?

It's not fixing a bug. Application does blocking operation and then uses a
mechanism that would abort that operation on Solaris. This mechanism
doesn't work on Linux. There is another mechanism that works on both; as
the matter of fact it works on every UNIX. You are asking to add the
former to Linux. Question: what for? It's not a demagogy, I honestly don't
see the rationale for that change. That's my problem with your suggestion
and I would really like to hear the explantion on that point.

-
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:21 EST