Resend: /proc/<pid>/maps offset output broken in 2.6.29

[Hugh Dickins]

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 http://lkml.org/lkml/2009/1/13/331 for one of the threads
on the subject - but you've not tempted me to reopen it!

Hugh