[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [-mm][PATCH 1/2] mm owner fix race between swap and exit
    On Mon, 11 Aug 2008 15:37:33 +0530
    Balbir Singh <> wrote:

    > There's a race between mm->owner assignment and try_to_unuse(). The condition
    > occurs when try_to_unuse() runs in parallel with an exiting task.
    > The race can be visualized below. To quote Hugh
    > "I don't think your careful alternation of CPU0/1 events at the end matters:
    > the swapoff CPU simply dereferences mm->owner after that task has gone"
    > But the alteration does help understand the race better (at-least for me :))
    > CPU0 CPU1
    > try_to_unuse
    > task 1 stars exiting look at mm = task1->mm
    > .. increment mm_users
    > task 1 exits
    > mm->owner needs to be updated, but
    > no new owner is found
    > (mm_users > 1, but no other task
    > has task->mm = task1->mm)
    > mm_update_next_owner() leaves
    > grace period
    > user count drops, call mmput(mm)
    > task 1 freed
    > dereferencing mm->owner fails
    > The fix is to notify the subsystem (via mm_owner_changed callback), if
    > no new owner is found by specifying the new task as NULL.

    This patch applies to mainline, 2.6.27-rc2 and even 2.6.26.

    Against which kernel/patch is it actually applicable?

    (If the answer was "all of the above" then please don't go embedding
    mainline bugfixes in the middle of a -mm-only patch series!)


     \ /
      Last update: 2008-08-12 02:35    [W:0.022 / U:63.904 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site