lkml.org 
[lkml]   [2002]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 <akpm@zip.com.au> 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:

    lock_kernel();
    sem_exit();
    // 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_files(tsk);
    __exit_fs(tsk);

    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)
    disassociate_ctty(1);

    // I can't see why these would need BKL. Looks safe
    put_exec_domain(tsk->exec_domain);
    if (tsk->binfmt && tsk->binfmt->module)
    __MOD_DEC_USE_COUNT(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?
    exit_notify();

    // BKL implicitly released by calling this, if it is held
    schedule();

    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
    theoretical.
    --
    Dave Hansen
    haveblue@us.ibm.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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