Hello!
> > It is nonportable _only_ to Linux (and to old freebsds btw,
> > its user level pthread library had the same bug).
>
> Huh?
Al, I specially wrote "old" freebsd, because I do not know anything
about new ones. At least, FreeBSD folks promised to fix this, when
they will implement their own linux-like threads. I even do not know,
did they imlemented them eventually or they did not. 8)
Their user-level thread library is surely buggy and this
is not the only bug there.
> And *BSD, unless they are using some userland wrappers around the read(2).
> Which may be the case, but then I don't see where it becomes a kernel
> problem on our end of things.
When kernel leaves process frozen, the bug is in kernel.
Did process close file? Yes. Does user have some references to this file
to control it? No! P...ts. All the arguments sort of "user is fool"
are pure demagogy. This thing is called "leakage" usually and for user
level it looks exactly as leakage. Kernel is not self-consistent. Period.
If you are still in doubts, look at analogies in FS.
You make "ls somedir" in one shell continuosuly.
You make "rmdir somedir; mkdir somedir" in another one.
You get lots of errors "No such directory", but processes
do not hang and unlinked but "still referenced by ls" directories
do not overflow file tables. User is surely makes some crap, but
it is his right 8).
Another analogy, look at mm_struct. It has mm_users and mm_count.
Why? Following situation with files, mm_count is enough. And bug
poor users, when mm is not cleared occasionally.
You can find the same logic in any object maintanance system.
Alexey
-
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