On Thu, 2 Apr 2009, Chris Friesen wrote:
Hugh Dickins wrote:
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
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
On Thu, 2 Apr 2009, Michael Ellerman wrote:
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 :)
Thanks.
I was validating
Hugh Dickins wrote:
On Thu, 2 Apr 2009, Michael Ellerman wrote:
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 :)
Thanks.
On Thu, 2 Apr 2009, Chris Friesen wrote:
Hugh Dickins wrote:
f7feb000-f7fec000 rw-p f7feb000 00:00 0
ffe6d000-ffe82000 rw-p ffeb000 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
Hugh Dickins wrote:
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.
snip
Consider this change a fix: it used to
Resending due to lack of response to original post.
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
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
