From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: hugh@veritas.com, mikew@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, yinghan@google.com
Subject: Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)
Date: Thu, 2 Apr 2009 13:18:16 -0700 [thread overview]
Message-ID: <20090402131816.54724d4e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090115114312.e42a0dba.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 15 Jan 2009 11:43:12 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Wed, 14 Jan 2009 14:08:35 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
>
> > On Wed, 14 Jan 2009, KAMEZAWA Hiroyuki wrote:
> > > Hmm, is this brutal ?
> > >
> > > ==
> > > Recently, it's argued that what proc/pid/maps shows is ugly when a
> > > 32bit binary runs on 64bit host.
> > >
> > > /proc/pid/maps outputs vma's pgoff member but vma->pgoff is of no use
> > > information is the vma is for ANON.
> > > By this patch, /proc/pid/maps shows just 0 if no file backing store.
> > >
> > > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > ---
> >
> > Brutal, but sensible enough: revert to how things looked before
> > we ever starting putting vm_pgoff to work on anonymous areas.
> >
> > I slightly regret losing that visible clue to whether an anonymous
> > vma has ever been mremap moved. But have I ever actually used that
> > info? No, never.
> >
> > I presume you test !vma->vm_file so the lines fit in, fair enough.
> > But I think you'll find checkpatch.pl protests at "(!vma->vm_file)?"
> >
> > I dislike its decisions on the punctuation of the ternary operator
> > - perhaps even more than Andrew dislikes the operator itself!
> > Do we write a space before a question mark? no: nor before a colon;
> > but I also dislike getting into checkpatch.pl arguments!
> >
> > While you're there, I'd also be inclined to make task_nommu.c
> > use the same loff_t cast as task_mmu.c is using.
> >
> Ok, I'll try to update to reasonable style.
>
afaik this update never happened?
Here's what I have at present:
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Recently, it's argued that what proc/pid/maps shows is ugly when a 32bit
binary runs on 64bit host.
/proc/pid/maps outputs vma's pgoff member but vma->pgoff is of no use
information is the vma is for ANON. With this patch, /proc/pid/maps shows
just 0 if no file backing store.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mike Waychison <mikew@google.com>
Reported-by: Ying Han <yinghan@google.com>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/task_mmu.c | 3 ++-
fs/proc/task_nommu.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff -puN fs/proc/task_mmu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas
+++ a/fs/proc/task_mmu.c
@@ -220,7 +220,8 @@ static void show_map_vma(struct seq_file
flags & VM_WRITE ? 'w' : '-',
flags & VM_EXEC ? 'x' : '-',
flags & VM_MAYSHARE ? 's' : 'p',
- ((loff_t)vma->vm_pgoff) << PAGE_SHIFT,
+ (!vma->vm_file) ? 0 :
+ ((loff_t)vma->vm_pgoff) << PAGE_SHIFT,
MAJOR(dev), MINOR(dev), ino, &len);
/*
diff -puN fs/proc/task_nommu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas fs/proc/task_nommu.c
--- a/fs/proc/task_nommu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas
+++ a/fs/proc/task_nommu.c
@@ -143,7 +143,8 @@ static int nommu_vma_show(struct seq_fil
flags & VM_WRITE ? 'w' : '-',
flags & VM_EXEC ? 'x' : '-',
flags & VM_MAYSHARE ? flags & VM_SHARED ? 'S' : 's' : 'p',
- (unsigned long long) vma->vm_pgoff << PAGE_SHIFT,
+ (!vma->vm_file) ? 0 :
+ (unsigned long long) vma->vm_pgoff << PAGE_SHIFT,
MAJOR(dev), MINOR(dev), ino, &len);
if (file) {
_
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: hugh@veritas.com, mikew@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, yinghan@google.com
Subject: Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)
Date: Thu, 2 Apr 2009 13:18:16 -0700 [thread overview]
Message-ID: <20090402131816.54724d4e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090115114312.e42a0dba.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 15 Jan 2009 11:43:12 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Wed, 14 Jan 2009 14:08:35 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
>
> > On Wed, 14 Jan 2009, KAMEZAWA Hiroyuki wrote:
> > > Hmm, is this brutal ?
> > >
> > > ==
> > > Recently, it's argued that what proc/pid/maps shows is ugly when a
> > > 32bit binary runs on 64bit host.
> > >
> > > /proc/pid/maps outputs vma's pgoff member but vma->pgoff is of no use
> > > information is the vma is for ANON.
> > > By this patch, /proc/pid/maps shows just 0 if no file backing store.
> > >
> > > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > ---
> >
> > Brutal, but sensible enough: revert to how things looked before
> > we ever starting putting vm_pgoff to work on anonymous areas.
> >
> > I slightly regret losing that visible clue to whether an anonymous
> > vma has ever been mremap moved. But have I ever actually used that
> > info? No, never.
> >
> > I presume you test !vma->vm_file so the lines fit in, fair enough.
> > But I think you'll find checkpatch.pl protests at "(!vma->vm_file)?"
> >
> > I dislike its decisions on the punctuation of the ternary operator
> > - perhaps even more than Andrew dislikes the operator itself!
> > Do we write a space before a question mark? no: nor before a colon;
> > but I also dislike getting into checkpatch.pl arguments!
> >
> > While you're there, I'd also be inclined to make task_nommu.c
> > use the same loff_t cast as task_mmu.c is using.
> >
> Ok, I'll try to update to reasonable style.
>
afaik this update never happened?
Here's what I have at present:
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Recently, it's argued that what proc/pid/maps shows is ugly when a 32bit
binary runs on 64bit host.
/proc/pid/maps outputs vma's pgoff member but vma->pgoff is of no use
information is the vma is for ANON. With this patch, /proc/pid/maps shows
just 0 if no file backing store.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mike Waychison <mikew@google.com>
Reported-by: Ying Han <yinghan@google.com>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/task_mmu.c | 3 ++-
fs/proc/task_nommu.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff -puN fs/proc/task_mmu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas
+++ a/fs/proc/task_mmu.c
@@ -220,7 +220,8 @@ static void show_map_vma(struct seq_file
flags & VM_WRITE ? 'w' : '-',
flags & VM_EXEC ? 'x' : '-',
flags & VM_MAYSHARE ? 's' : 'p',
- ((loff_t)vma->vm_pgoff) << PAGE_SHIFT,
+ (!vma->vm_file) ? 0 :
+ ((loff_t)vma->vm_pgoff) << PAGE_SHIFT,
MAJOR(dev), MINOR(dev), ino, &len);
/*
diff -puN fs/proc/task_nommu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas fs/proc/task_nommu.c
--- a/fs/proc/task_nommu.c~proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas
+++ a/fs/proc/task_nommu.c
@@ -143,7 +143,8 @@ static int nommu_vma_show(struct seq_fil
flags & VM_WRITE ? 'w' : '-',
flags & VM_EXEC ? 'x' : '-',
flags & VM_MAYSHARE ? flags & VM_SHARED ? 'S' : 's' : 'p',
- (unsigned long long) vma->vm_pgoff << PAGE_SHIFT,
+ (!vma->vm_file) ? 0 :
+ (unsigned long long) vma->vm_pgoff << PAGE_SHIFT,
MAJOR(dev), MINOR(dev), ino, &len);
if (file) {
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-04-02 20:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 0:53 mmotm 2009-01-12-16-53 uploaded akpm
2009-01-13 1:54 ` mmotm 2009-01-12-16-53 uploaded (rtc-cmos) Randy Dunlap
2009-01-13 9:13 ` mmotm 2009-01-12-16-53 uploaded KAMEZAWA Hiroyuki
2009-01-13 9:13 ` KAMEZAWA Hiroyuki
2009-01-13 17:05 ` Mike Waychison
2009-01-13 17:05 ` Mike Waychison
2009-01-14 7:22 ` [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded) KAMEZAWA Hiroyuki
2009-01-14 7:22 ` KAMEZAWA Hiroyuki
2009-01-14 14:08 ` Hugh Dickins
2009-01-14 14:08 ` Hugh Dickins
2009-01-15 2:43 ` KAMEZAWA Hiroyuki
2009-01-15 2:43 ` KAMEZAWA Hiroyuki
2009-04-02 20:18 ` Andrew Morton [this message]
2009-04-02 20:18 ` Andrew Morton
2009-04-03 0:27 ` KAMEZAWA Hiroyuki
2009-04-03 0:27 ` KAMEZAWA Hiroyuki
2009-04-03 1:25 ` [PATCH] proc pid maps dont show pgoff of pure anon vmas style fix (WasRe: " KAMEZAWA Hiroyuki
2009-04-03 1:25 ` KAMEZAWA Hiroyuki
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=20090402131816.54724d4e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikew@google.com \
--cc=yinghan@google.com \
/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.