On Sun, 27 Aug 2000 kuznet@ms2.inr.ac.ru wrote:
> > 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.
WTF "frozen"? Does
% cat
leave the process frozen? Not? If your read() is uninterruptably blocked -
too fscking bad, but close() is unlikely to get you out of that. If it
isn't - what are you complaining about?
> 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"
OK, should unlink("foo"); terminate truncate("foo", 1);?
Kstati, eto ne p..ts, a h...nya. I my takogo ne lechim...
> 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).
Alexey, I'm afraid that I've got a surprise for you. Say rmdir `pwd`
and see if the inode gets released. It doesn' and it shouldn't. Nothing
is getting hung, indeed.
> 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.
Excuse me? Sorry, but you've totally misread that code. If the last owner
of mm_struct exits while the thing is in use by some processor running
lazy-TLB process... Guess what - mm_struct hangs around until the next
context switch to non-lazy beast. On all CPUs that had it.
> 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