[lkml]   [2002]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectBKL in do_exit
    I was asked by a coworker why the BKL was held in do_exit().  I didn't 
    have a good answer for him, so I went digging and found a couple of
    Linus quotations on the subject (thank you Google).

    > And the do_exit() case should be _trivial_ to fix: almost none of the
    > code protected by the kernel lock in the exit path actually needs the
    > lock. I suspect you could cut down the kernel lock there to much
    > smaller.

    > Andrew Morton <> wrote:
    >>That'll be where exit() takes down the tasks's address spaces.
    >>zap_page_range(). That's a nasty one.
    > No, lock_kernel happens after exit_mm, and in fact I suspect it's not
    > really needed at all any more except for the current "sem_exit()". I
    > think most everything else is threaded already.
    > (Hmm.. Maybe disassociate_ctty() too).
    > So minimizing the BLK footprint in do_exit() should be pretty much
    > trivial: all the really interesting stuff should be ok already.

    Because of Linus's optimism, I went looking at do_exit(). Here is my
    take on it:

    // This is questionable, but appears safe to me. Several
    // sem_(un)lock()s are done the semid. What else needs to be protected
    // here? What was Linus talking about that looks unsafe? Is there a
    // chance for another process to be mucking with the current process's
    // semaphore lists?

    // these hold the task lock and look safe

    exit_sighand(tsk); // does spin_lock_irq(&tsk->sigmask_lock);
    // looks safe

    exit_thread(); // nop on most architectures
    // FPU cleanup on most others
    // looks safe

    // there is no locking of the tty. As Linus said, this appears to
    // be the bad one now
    if (current->leader)

    // I can't see why these would need BKL. Looks safe
    if (tsk->binfmt && tsk->binfmt->module)

    // Does the task lock need to be taken for this?
    tsk->exit_code = code;

    // Does this need to make sure that none of the relatives exit?

    // BKL implicitly released by calling this, if it is held

    Can we just hold the BKL around the operations that actually need it?
    Is there any other reason to hold it the whole time?

    P.S. There are some really fork-happy benchmarks which could see an
    improvement from a reduction of lock contention here. It isn't just
    Dave Hansen

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.026 / U:1.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site