[lkml]   [2008]   [Aug]   [12]   [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
    Andrew Morton wrote:
    > 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!)


    The answer is all, but the bug is not exposed *outside* of the memrlimit
    controller, thus the push into -mm. I can redo and rework the patches for
    mainline if required and pull it out of -mm.

    Warm Regards,
    Balbir Singh
    Linux Technology Center

     \ /
      Last update: 2008-08-12 06:11    [W:0.024 / U:0.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site