[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] thread wakeup fix for 2.4.0-test7

    On Sun, 27 Aug 2000 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:2.375 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site