On Mon, 12 Jan 2009 16:53:43 -0800
[email protected] 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 <[email protected]>
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 <[email protected]>
---
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);
KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jan 2009 16:53:43 -0800
> [email protected] 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 <[email protected]>
>
> 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 <[email protected]>
> ---
> 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.
On Tue, 13 Jan 2009 09:05:28 -0800
Mike Waychison <[email protected]> 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 <[email protected]>
---
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) {
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 <[email protected]>
> ---
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) {
>
On Wed, 14 Jan 2009 14:08:35 +0000 (GMT)
Hugh Dickins <[email protected]> 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 <[email protected]>
> > ---
>
> 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) {
> >
>
On Thu, 15 Jan 2009 11:43:12 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
> On Wed, 14 Jan 2009 14:08:35 +0000 (GMT)
> Hugh Dickins <[email protected]> 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 <[email protected]>
> > > ---
> >
> > 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 <[email protected]>
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.
[[email protected]: coding-style fixes]
Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
Cc: Mike Waychison <[email protected]>
Reported-by: Ying Han <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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) {
_
On Thu, 2 Apr 2009 13:18:16 -0700
Andrew Morton <[email protected]> wrote:
> On Thu, 15 Jan 2009 11:43:12 +0900
> KAMEZAWA Hiroyuki <[email protected]> wrote:
>
> > On Wed, 14 Jan 2009 14:08:35 +0000 (GMT)
> > Hugh Dickins <[email protected]> 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 <[email protected]>
> > > > ---
> > >
> > > 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 <[email protected]>
>
> 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.
>
> [[email protected]: coding-style fixes]
> Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
> Cc: Mike Waychison <[email protected]>
> Reported-by: Ying Han <[email protected]>
> Cc: Hugh Dickins <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I wrote this on mmotm-Mar23 as 2.6.29-rc8-mm1. Is this ok ?
==
From: KAMEZAWA Hiroyuki <[email protected]>
Fix condig style of proc-pid-maps-dont-show-pgoff-of-pure-anon-vmas.patch
Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
---
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) {