[lkml]   [2010]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA
    On 04/07/2010 06:15 PM, Linus Torvalds wrote:
    > On Wed, 7 Apr 2010, Linus Torvalds wrote:
    >> In the long run, it would be nicer to actually return an error from the
    >> mmap() that fails, but that's more complicated, and as mentioned, it's not
    >> what the old code used to do either (since the failure point was always at
    >> the page fault stage).
    > Put another way: I'm not proud of it, but the new code isn't any worse
    > than what we used to have, and I think the new code is _fixable_.

    Agreed, it is no worse than what we had before.

    As to fixable, I supect both situations are fixable.
    The new code by getting the error paths right, the
    old code by completely bailing out of the page fault
    and retrying it (the pageout code should trigger an
    OOM kill at some point, if we are really out of memory).

    > The easiest way to do that would likely be to pre-allocate the anon_vma
    > struct (and anon_vma_chain), and pass it down to anon_vma_prepare. That
    > way anon_vma_prepare() itself can never fail, and all we need to do is a
    > simple allocation earlier in the call-chain.

    That may not work, because we may want to merge the anon_vma
    with the anon_vma in an adjacant VMA ... and that adjacant
    VMA could be chained onto multiple anon_vmas.

    That means allocating a single anon_vma_chain may not be

     \ /
      Last update: 2010-04-08 02:43    [W:0.019 / U:12.828 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site