Re: mmotm 2009-01-12-16-53 uploaded

Re: mmotm 2009-01-12-16-53 uploaded

[KAMEZAWA Hiroyuki]

On Mon, 12 Jan 2009 16:53:43 -0800
akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2009-01-12-16-53 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> and will soon be available at
> 
>    git://git.zen-sources.org/zen/mmotm.git
> 

After rtc compile fix, the kernel boots.

But with CONFIG_DEBUG_VM, I saw BUG_ON() at 

fork() -> ...
	-> copy_page_range() ...
		-> copy_one_pte()
			->page_dup_rmap()
				-> __page_check_anon_rmap().

BUG_ON(page->index != linear_page_index(vma, address)); 
fires. (from above, the page is ANON.)

It seems page->index == 0x7FFFFFFE here and the page seems to be
the highest address of stack.

This is caused by
 fs-execc-fix-value-of-vma-vm_pgoff-for-the-stack-vma-of-32-bit-processes.patch 


This is a fix.
==
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

pgoff is *not* vma->vm_start >> PAGE_SHIFT.
And no adjustment is necessary (when it maps the same start
before/after adjust vma.)

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
Index: mmotm-2.6.29-Jan12/fs/exec.c
===================================================================
--- mmotm-2.6.29-Jan12.orig/fs/exec.c
+++ mmotm-2.6.29-Jan12/fs/exec.c
@@ -509,7 +509,7 @@ static int shift_arg_pages(struct vm_are
 	unsigned long length = old_end - old_start;
 	unsigned long new_start = old_start - shift;
 	unsigned long new_end = old_end - shift;
-	unsigned long new_pgoff = new_start >> PAGE_SHIFT;
+	unsigned long new_pgoff = vma->vm_pgoff;
 	struct mmu_gather *tlb;
 
 	BUG_ON(new_start > new_end);

--
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>

Re: mmotm 2009-01-12-16-53 uploaded

[Mike Waychison]

KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jan 2009 16:53:43 -0800
> akpm@linux-foundation.org wrote:
> 
>> The mm-of-the-moment snapshot 2009-01-12-16-53 has been uploaded to
>>
>>    http://userweb.kernel.org/~akpm/mmotm/
>>
>> and will soon be available at
>>
>>    git://git.zen-sources.org/zen/mmotm.git
>>
> 
> After rtc compile fix, the kernel boots.
> 
> But with CONFIG_DEBUG_VM, I saw BUG_ON() at 
> 
> fork() -> ...
> 	-> copy_page_range() ...
> 		-> copy_one_pte()
> 			->page_dup_rmap()
> 				-> __page_check_anon_rmap().
> 
> BUG_ON(page->index != linear_page_index(vma, address)); 
> fires. (from above, the page is ANON.)
> 
> It seems page->index == 0x7FFFFFFE here and the page seems to be
> the highest address of stack.
> 
> This is caused by
>  fs-execc-fix-value-of-vma-vm_pgoff-for-the-stack-vma-of-32-bit-processes.patch 
> 
> 
> This is a fix.
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> 
> pgoff is *not* vma->vm_start >> PAGE_SHIFT.
> And no adjustment is necessary (when it maps the same start
> before/after adjust vma.)
> 
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> Index: mmotm-2.6.29-Jan12/fs/exec.c
> ===================================================================
> --- mmotm-2.6.29-Jan12.orig/fs/exec.c
> +++ mmotm-2.6.29-Jan12/fs/exec.c
> @@ -509,7 +509,7 @@ static int shift_arg_pages(struct vm_are
>  	unsigned long length = old_end - old_start;
>  	unsigned long new_start = old_start - shift;
>  	unsigned long new_end = old_end - shift;
> -	unsigned long new_pgoff = new_start >> PAGE_SHIFT;
> +	unsigned long new_pgoff = vma->vm_pgoff;
>  	struct mmu_gather *tlb;
>  
>  	BUG_ON(new_start > new_end);
> 

This patch is just reverting the behaviour back to having a 64bit pgoff. 
  Best just reverting the patch for the time being.

--
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>

[RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[KAMEZAWA Hiroyuki]

On Tue, 13 Jan 2009 09:05:28 -0800
Mike Waychison <mikew@google.com> wrote:


> > ===================================================================
> > --- mmotm-2.6.29-Jan12.orig/fs/exec.c
> > +++ mmotm-2.6.29-Jan12/fs/exec.c
> > @@ -509,7 +509,7 @@ static int shift_arg_pages(struct vm_are
> >  	unsigned long length = old_end - old_start;
> >  	unsigned long new_start = old_start - shift;
> >  	unsigned long new_end = old_end - shift;
> > -	unsigned long new_pgoff = new_start >> PAGE_SHIFT;
> > +	unsigned long new_pgoff = vma->vm_pgoff;
> >  	struct mmu_gather *tlb;
> >  
> >  	BUG_ON(new_start > new_end);
> > 
> 
> This patch is just reverting the behaviour back to having a 64bit pgoff. 
>   Best just reverting the patch for the time being.
> 
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>
---
Index: mmotm-2.6.29-Jan13/fs/proc/task_mmu.c
===================================================================
--- mmotm-2.6.29-Jan13.orig/fs/proc/task_mmu.c
+++ mmotm-2.6.29-Jan13/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);
 
 	/*
Index: mmotm-2.6.29-Jan13/fs/proc/task_nommu.c
===================================================================
--- mmotm-2.6.29-Jan13.orig/fs/proc/task_nommu.c
+++ mmotm-2.6.29-Jan13/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>

Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[Hugh Dickins]

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.

Hugh

> Index: mmotm-2.6.29-Jan13/fs/proc/task_mmu.c
> ===================================================================
> --- mmotm-2.6.29-Jan13.orig/fs/proc/task_mmu.c
> +++ mmotm-2.6.29-Jan13/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);
>  
>  	/*
> Index: mmotm-2.6.29-Jan13/fs/proc/task_nommu.c
> ===================================================================
> --- mmotm-2.6.29-Jan13.orig/fs/proc/task_nommu.c
> +++ mmotm-2.6.29-Jan13/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>

Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[KAMEZAWA Hiroyuki]

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.

Thanks,
-Kame


> Hugh
> 
> > Index: mmotm-2.6.29-Jan13/fs/proc/task_mmu.c
> > ===================================================================
> > --- mmotm-2.6.29-Jan13.orig/fs/proc/task_mmu.c
> > +++ mmotm-2.6.29-Jan13/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);
> >  
> >  	/*
> > Index: mmotm-2.6.29-Jan13/fs/proc/task_nommu.c
> > ===================================================================
> > --- mmotm-2.6.29-Jan13.orig/fs/proc/task_nommu.c
> > +++ mmotm-2.6.29-Jan13/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>

Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[Andrew Morton]

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>

Re: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[KAMEZAWA Hiroyuki]

On Thu, 2 Apr 2009 13:18:16 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 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?
> 
Ouch, sorry..could you wait ? I'll do soon....

-Kame

> 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 from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
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>

[PATCH] proc pid maps dont show pgoff of pure anon vmas style fix (WasRe: [RFC][PATCH] don't show pgoff of vma if vma is pure ANON (was Re: mmotm 2009-01-12-16-53 uploaded)

[KAMEZAWA Hiroyuki]

I wrote this on mmotm-Mar23 as 2.6.29-rc8-mm1. Is this ok ?
==
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

Fix condig style of proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas.patch

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
 fs/proc/task_mmu.c   |    5 +++--
 fs/proc/task_nommu.c |    5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

Index: mmotm-2.6.29-rc8-mm1/fs/proc/task_mmu.c
===================================================================
--- mmotm-2.6.29-rc8-mm1.orig/fs/proc/task_mmu.c
+++ mmotm-2.6.29-rc8-mm1/fs/proc/task_mmu.c
@@ -204,6 +204,7 @@ static void show_map_vma(struct seq_file
 	struct file *file = vma->vm_file;
 	int flags = vma->vm_flags;
 	unsigned long ino = 0;
+	unsigned long long pgoff = 0;
 	dev_t dev = 0;
 	int len;
 
@@ -211,6 +212,7 @@ static void show_map_vma(struct seq_file
 		struct inode *inode = vma->vm_file->f_path.dentry->d_inode;
 		dev = inode->i_sb->s_dev;
 		ino = inode->i_ino;
+		pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT;
 	}
 
 	seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu %n",
@@ -220,8 +222,7 @@ static void show_map_vma(struct seq_file
 			flags & VM_WRITE ? 'w' : '-',
 			flags & VM_EXEC ? 'x' : '-',
 			flags & VM_MAYSHARE ? 's' : 'p',
-			(!vma->vm_file) ? 0 :
-				((loff_t)vma->vm_pgoff) << PAGE_SHIFT,
+			pgoff,
 			MAJOR(dev), MINOR(dev), ino, &len);
 
 	/*
Index: mmotm-2.6.29-rc8-mm1/fs/proc/task_nommu.c
===================================================================
--- mmotm-2.6.29-rc8-mm1.orig/fs/proc/task_nommu.c
+++ mmotm-2.6.29-rc8-mm1/fs/proc/task_nommu.c
@@ -125,6 +125,7 @@ static int nommu_vma_show(struct seq_fil
 	struct file *file;
 	dev_t dev = 0;
 	int flags, len;
+	unsigned long long pgoff = 0;
 
 	flags = vma->vm_flags;
 	file = vma->vm_file;
@@ -133,6 +134,7 @@ static int nommu_vma_show(struct seq_fil
 		struct inode *inode = vma->vm_file->f_path.dentry->d_inode;
 		dev = inode->i_sb->s_dev;
 		ino = inode->i_ino;
+		pgoff = (loff_t)vma->pg_off << PAGE_SHIFT;
 	}
 
 	seq_printf(m,
@@ -143,8 +145,7 @@ 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',
-		   (!vma->vm_file) ? 0 :
-			(unsigned long long) vma->vm_pgoff << PAGE_SHIFT,
+		   pgoff,
 		   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>