[lkml]   [2012]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/6] mempolicy memory corruption fixlet
    From: KOSAKI Motohiro <>

    Hi Linus and all

    Sorry for the long long delay.

    Maybe I've finished a code auditing of mempolicy.c. It was hard work, multiple
    mistakes hided real issues. :-/

    Yes, my code auditing is too slow as usual, I know. But probably a slow work is
    better than do nothing, maybe.

    Sadly, I've found multiple long living bugs and almost patches in this area were
    committed with no review. That's sad. Therefore, I'd like to maintain this area
    a while (hopefully short) until known breakage will be fixed or finding another
    volunteer. The purpose is not developing new feature. It is preventing more
    corruption until known issue is fixed. (Of course, if anyone want to take the role,
    I'm really happy and drop patch 6/6.

    Here are some bandaid fixing patch set for mempolicy. It may fix all known uservisible
    corruptions. But, I know, we have a lot of remained work. Below are unfixed issues.
    (because of, they are broken by design. I can't fix them w/o design change)

    1) mpol mount option of tmpfs doesn't work correctly

    When not using =static mount option modifier, a nodemask is affected cpuset restriction
    of *inode creation* thread and ignore page allocation thread.

    2) cpuset rebinding doesn't work correctly if shmem are shared from multiple processes.

    mbind(2) (and set_mempolicy(2)) stores pre-calculated mask, say,
    (mbind-mask & cpuset-mask & online-nodes-mask) into struct mempolicy.
    and the mempolicy attaches vma and shmem regions. But, of course,
    cpuset-mask depend on a thread. Thus we can't calculate final node mask
    on ahead.

    3) mbind(2) doesn't work correctly if shmem are shared from multiple processes.

    The same of (2). mbind(2) stores final nodemask, but another thread have another
    final node mask. The calculation is incorrect.

    So, I think we should reconsider about shared mempolicy completely. If my remember
    is correct, Hugh said he worry about this feature because nobody seems
    to use and lots bug about 4 years ago. As usually he is, he is correct. now, I'm
    convinced nobody uses this feature. Current all of my patches are trivial and
    we can easily reproduce kernel memory corruption. And it don't work proper
    functionality (see above todo list). Thus, I'd like to hear his opinion. if he
    still dislike shared mempolicy feature, I'm ok to remove it entirely instead of
    applying current bandaid patch set.

    Thank you.

    KOSAKI Motohiro (6):
    Revert "mm: mempolicy: Let vma_merge and vma_split handle
    vma->vm_policy linkages"
    mempolicy: Kill all mempolicy sharing
    mempolicy: fix a race in shared_policy_replace()
    mempolicy: fix refcount leak in mpol_set_shared_policy()
    mempolicy: fix a memory corruption by refcount imbalance in

    MAINTAINERS | 7 +++
    mm/mempolicy.c | 151 ++++++++++++++++++++++++++++++++++++++++----------------
    mm/shmem.c | 9 ++--
    3 files changed, 120 insertions(+), 47 deletions(-)

     \ /
      Last update: 2012-05-30 11:41    [W:0.030 / U:4.896 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site