From: Michael Ellerman <michael@ellerman.id.au>
To: Chris Friesen <cfriesen@nortel.com>
Cc: peterz@infradead.org, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
Date: Thu, 02 Apr 2009 19:04:51 +1100 [thread overview]
Message-ID: <1238659491.9041.133.camel@localhost> (raw)
In-Reply-To: <49D3F662.4050100@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
> was surprised when it failed. It turns out that at least on my ppc64 G5
> machine the offset value for the last entry is strange--it shows up as a
> 64-bit value even though the process itself is only 32-bit.
>
> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
> haven't yet tested anything else in between.
>
> [cfriesen@localhost cfriesen]$ cat /proc/self/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
> 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
> 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
> 10015000-10036000 rwxp 10015000 00:00 0 [heap]
> f7deb000-f7feb000 r--p 00000000 08:03 2560322
> /usr/lib/locale/locale-archive
> f7feb000-f7fec000 rw-p f7feb000 00:00 0
> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
>
> I'm at a loss to explain what's going on here. Anyone got any ideas?
It looks like for vmas that don't have a vm_file (like the stack),
vm_pgoff is basically "internal use" - and so can be > 32 bit.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Chris Friesen <cfriesen@nortel.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
peterz@infradead.org
Subject: Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
Date: Thu, 02 Apr 2009 19:04:51 +1100 [thread overview]
Message-ID: <1238659491.9041.133.camel@localhost> (raw)
In-Reply-To: <49D3F662.4050100@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
> was surprised when it failed. It turns out that at least on my ppc64 G5
> machine the offset value for the last entry is strange--it shows up as a
> 64-bit value even though the process itself is only 32-bit.
>
> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
> haven't yet tested anything else in between.
>
> [cfriesen@localhost cfriesen]$ cat /proc/self/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
> 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
> 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
> 10015000-10036000 rwxp 10015000 00:00 0 [heap]
> f7deb000-f7feb000 r--p 00000000 08:03 2560322
> /usr/lib/locale/locale-archive
> f7feb000-f7fec000 rw-p f7feb000 00:00 0
> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
>
> I'm at a loss to explain what's going on here. Anyone got any ideas?
It looks like for vmas that don't have a vm_file (like the stack),
vm_pgoff is basically "internal use" - and so can be > 32 bit.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-04-02 8:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 19:24 /proc/<pid>/maps offset output broken Chris Friesen
2009-04-01 23:18 ` Resend: /proc/<pid>/maps offset output broken in 2.6.29 Chris Friesen
2009-04-02 8:04 ` Michael Ellerman [this message]
2009-04-02 8:04 ` Michael Ellerman
2009-04-02 12:43 ` Hugh Dickins
2009-04-02 12:43 ` Hugh Dickins
2009-04-02 17:53 ` Chris Friesen
2009-04-02 17:53 ` Chris Friesen
2009-04-02 19:10 ` Hugh Dickins
2009-04-02 19:10 ` Hugh Dickins
2009-04-02 20:45 ` Chris Friesen
2009-04-02 20:45 ` Chris Friesen
2009-04-05 18:51 ` Hugh Dickins
2009-04-05 18:51 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1238659491.9041.133.camel@localhost \
--to=michael@ellerman.id.au \
--cc=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.