Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1385505 > unrolled thread

[PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU

Back to article view | Back to linux.kernel

Contents

  [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Rich Felker <dalias@libc.org> - 2016-04-23 00:30 +0200
    Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Andrew Morton <akpm@linux-foundation.org> - 2016-04-26 02:10 +0200
      Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Rich Felker <dalias@libc.org> - 2016-04-26 02:50 +0200
        Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Rich Felker <dalias@libc.org> - 2016-04-26 02:50 +0200
          Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Andrew Morton <akpm@linux-foundation.org> - 2016-04-26 04:50 +0200

#1385505 — [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU

The nommu do_mmap expects f_op->get_unmapped_area to either succeed or
return -ENOSYS for VM_MAYSHARE (e.g. private read-only) mappings.
Returning addr in the non-MAP_SHARED case was completely wrong, and
only happened to work because addr was 0. However, it prevented
VM_MAYSHARE mappings from sharing backing with the fs cache, and
forced such mappings (including shareable program text) to be copied
whenever the number of mappings transitioned from 0 to 1, impacting
performance and memory usage. Subsequent mappings beyond the first
still correctly shared memory with the first.

Instead, treat VM_MAYSHARE identically to VM_SHARED at the file ops
level; do_mmap already handles the semantic differences between them.

Signed-off-by: Rich Felker <dalias@libc.org>
---
 fs/ramfs/file-nommu.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index a586467..be3ddd1 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -211,14 +211,11 @@ static unsigned long ramfs_nommu_get_unmapped_area(struct file *file,
 	struct page **pages = NULL, **ptr, *page;
 	loff_t isize;
 
-	if (!(flags & MAP_SHARED))
-		return addr;
-
 	/* the mapping mustn't extend beyond the EOF */
 	lpages = (len + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	isize = i_size_read(inode);
 
-	ret = -EINVAL;
+	ret = -ENOSYS;
 	maxpages = (isize + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	if (pgoff >= maxpages)
 		goto out;
@@ -227,7 +224,6 @@ static unsigned long ramfs_nommu_get_unmapped_area(struct file *file,
 		goto out;
 
 	/* gang-find the pages */
-	ret = -ENOMEM;
 	pages = kcalloc(lpages, sizeof(struct page *), GFP_KERNEL);
 	if (!pages)
 		goto out_free;
@@ -263,7 +259,7 @@ out:
  */
 static int ramfs_nommu_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	if (!(vma->vm_flags & VM_SHARED))
+	if (!(vma->vm_flags & (VM_SHARED | VM_MAYSHARE)))
 		return -ENOSYS;
 
 	file_accessed(file);
-- 
2.7.0

[toc] | [next] | [standalone]

#1387019

On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker <dalias@libc.org> wrote:

> Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU

I take it that "ramfs" was intended here.

> The nommu do_mmap expects f_op->get_unmapped_area to either succeed or
> return -ENOSYS for VM_MAYSHARE (e.g. private read-only) mappings.
> Returning addr in the non-MAP_SHARED case was completely wrong, and
> only happened to work because addr was 0. However, it prevented
> VM_MAYSHARE mappings from sharing backing with the fs cache, and
> forced such mappings (including shareable program text) to be copied
> whenever the number of mappings transitioned from 0 to 1, impacting
> performance and memory usage. Subsequent mappings beyond the first
> still correctly shared memory with the first.
> 
> Instead, treat VM_MAYSHARE identically to VM_SHARED at the file ops
> level; do_mmap already handles the semantic differences between them.
>
> ...
>

[toc] | [prev] | [next] | [standalone]

#1387032

On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote:
> On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker <dalias@libc.org> wrote:
> 
> > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU
> 
> I take it that "ramfs" was intended here.

They're two names for the same thing; I'm not sure which should be
preferred.

Rich


> 
> > The nommu do_mmap expects f_op->get_unmapped_area to either succeed or
> > return -ENOSYS for VM_MAYSHARE (e.g. private read-only) mappings.
> > Returning addr in the non-MAP_SHARED case was completely wrong, and
> > only happened to work because addr was 0. However, it prevented
> > VM_MAYSHARE mappings from sharing backing with the fs cache, and
> > forced such mappings (including shareable program text) to be copied
> > whenever the number of mappings transitioned from 0 to 1, impacting
> > performance and memory usage. Subsequent mappings beyond the first
> > still correctly shared memory with the first.
> > 
> > Instead, treat VM_MAYSHARE identically to VM_SHARED at the file ops
> > level; do_mmap already handles the semantic differences between them.
> >
> > ...
> >

[toc] | [prev] | [next] | [standalone]

#1387036

On Mon, Apr 25, 2016 at 08:41:24PM -0400, Rich Felker wrote:
> On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote:
> > On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker <dalias@libc.org> wrote:
> > 
> > > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU
> > 
> > I take it that "ramfs" was intended here.
> 
> They're two names for the same thing; I'm not sure which should be
> preferred.

Or maybe not... the relationship seems more complex, at least
hisorically, but the ramfs code here is what seems to provide the
backing for tmpfs (and maybe more?). Sorry for the quick and imprecise
reply.

Rich


> > > The nommu do_mmap expects f_op->get_unmapped_area to either succeed or
> > > return -ENOSYS for VM_MAYSHARE (e.g. private read-only) mappings.
> > > Returning addr in the non-MAP_SHARED case was completely wrong, and
> > > only happened to work because addr was 0. However, it prevented
> > > VM_MAYSHARE mappings from sharing backing with the fs cache, and
> > > forced such mappings (including shareable program text) to be copied
> > > whenever the number of mappings transitioned from 0 to 1, impacting
> > > performance and memory usage. Subsequent mappings beyond the first
> > > still correctly shared memory with the first.
> > > 
> > > Instead, treat VM_MAYSHARE identically to VM_SHARED at the file ops
> > > level; do_mmap already handles the semantic differences between them.
> > >
> > > ...
> > >

[toc] | [prev] | [next] | [standalone]

#1387103

On Mon, 25 Apr 2016 20:47:45 -0400 Rich Felker <dalias@libc.org> wrote:

> On Mon, Apr 25, 2016 at 08:41:24PM -0400, Rich Felker wrote:
> > On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote:
> > > On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker <dalias@libc.org> wrote:
> > > 
> > > > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU
> > > 
> > > I take it that "ramfs" was intended here.
> > 
> > They're two names for the same thing; I'm not sure which should be
> > preferred.
> 
> Or maybe not... the relationship seems more complex, at least
> hisorically, but the ramfs code here is what seems to provide the
> backing for tmpfs (and maybe more?). Sorry for the quick and imprecise
> reply.

I am a simple soul.

Subject: tmpfs/ramfs: fix VM_MAYSHARE mappings for NOMMU

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web