[lkml]   [2009]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Resend: /proc/<pid>/maps offset output broken in 2.6.29
    On Thu, 2 Apr 2009, Chris Friesen wrote:
    > Hugh Dickins wrote:
    > > > > f7feb000-f7fec000 rw-p f7feb000 00:00 0
    > > > > ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
    > > Chris isn't the first to be concerned by that: there's a patch in
    > > -mm which just shows 0 instead of anon vm_pgoff in /proc/<pid>/maps
    > > output. That patch is on akpm's list for 2.6.30 merge, but I think
    > > hasn't gone to Linus yet: expect it in a later batch.
    > Alternately, what about just making the offset for the stack match the
    > starting address of the VMA?

    The rmap code for locating anonymous pages, even after the vma has
    been moved meanwhile, depends on vma->vm_pgoff. There is no point
    in making that more complicated for this.

    For display purposes only? Well, yes, we could have done that,
    but why bother? It wouldn't be adding any information, and
    might raise a question of identifying "the" stack to do that to.

    > That way it would look the same as other anonymous areas,

    The stack will be looking the same as other anonymous areas:
    they'll all be showing 00000000 there.

    This is a cosmetic matter, not worth more than a couple of lines of
    code: I suggested masking off the high bits in the display, but when
    KAMEZAWA-san suggested just showing 0, it was hard to argue against
    his brutal simplicity.

    > and as a bonus would look the same as previous releases.
    > Arguably, /proc/<pid>/maps should count as userspace-visible API.

    Consider this change a fix: it used to show 00000000 before 2.6.7.

    See for one of the threads
    on the subject - but you've not tempted me to reopen it!


     \ /
      Last update: 2009-04-02 21:15    [W:0.039 / U:4.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site