Messages in this thread |  | | Date | Sun, 27 Aug 2000 15:18:16 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
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/
|  |