lkml.org 
[lkml]   [2015]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Regression: Requiring CAP_SYS_ADMIN for /proc/<pid>/pagemap causes application-level breakage
    From
    On Wed, Apr 29, 2015 at 10:02 PM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    > On Wed, Apr 29, 2015 at 1:44 PM, Konstantin Khlebnikov <koct9i@gmail.com> wrote:
    >>
    >> This's no longer true. After recent fixes for "anon_vma endless growing" new vma
    >> might reuse old anon_vma from grandparent vma.
    >
    > Oh well. I guess that was too simple.
    >
    > If Mark is ok with the rule that "it's not reliably if you have two
    > nested forks" (ie it only works if you exec for every fork you do), it
    > should still work, right? It sounds like Mark doesn't necessarily need
    > to handle the *generic* case.

    Yes, it sounds like that should be OK for us. Our usecase is pretty
    restricted, so we're a long way off requiring a generic solution.

    Our code will always fork() a fresh child in which to monitor memory
    changes. We run the operations we're interested in, use pagemap to
    figure out "what changed" (by comparing whether the pagemap_entry_t
    values are different from their parent) and then throw away the child
    process.

    Currently our code does an entry-by-entry compare of pagemap, so
    anything that exposes writes as a change to values in there would
    allow us to run unmodified. That would be really nice. That said, I
    think we'd still be OK to modify our own code too if we can find a
    solution that would continue to function on older kernel releases,
    -stable trees, etc.

    Thanks,
    Mark


    \
     
     \ /
      Last update: 2015-04-30 14:21    [W:4.126 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site