+ procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Subject: + procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch added to -mm tree
To: JBeulich@xxxxxxxx,adobriyan@xxxxxxxxx,d.hatayama@xxxxxxxxxxxxxx,davem@xxxxxxxxxxxxx,jbeulich@xxxxxxxx,stable@xxxxxxxxxxxxxxx
From: akpm@xxxxxxxxxxxxxxxxxxxx
Date: Mon, 25 Nov 2013 14:13:43 -0800


The patch titled
     Subject: procfs: also fix proc_reg_get_unmapped_area() for !MMU case
has been added to the -mm tree.  Its filename is
     procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Subject: procfs: also fix proc_reg_get_unmapped_area() for !MMU case

Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
architectures"), as its title says, took care of only the MMU case,
leaving the !MMU side still in the regressed state (returning -EIO in all
cases where pde->proc_fops->get_unmapped_area is NULL).

>From the fad1a86e changelog:

: Commit c4fe24485729 ("sparc: fix PCI device proc file mmap(2)") added
: proc_reg_get_unmapped_area in proc_reg_file_ops and
: proc_reg_file_ops_no_compat, by which now mmap always returns EIO if
: get_unmapped_area method is not defined for the target procfs file, which
: causes regression of mmap on /proc/vmcore.
: 
: To address this issue, like get_unmapped_area(), call default
: current->mm->get_unmapped_area on MMU-present architectures if
: pde->proc_fops->get_unmapped_area, i.e.  the one in actual file operation
: in the procfs file, is not defined.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Cc: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx>
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>
Cc: David S. Miller <davem@xxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>	[3.12.x]
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 fs/proc/inode.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff -puN fs/proc/inode.c~procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case fs/proc/inode.c
--- a/fs/proc/inode.c~procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case
+++ a/fs/proc/inode.c
@@ -292,16 +292,19 @@ proc_reg_get_unmapped_area(struct file *
 {
 	struct proc_dir_entry *pde = PDE(file_inode(file));
 	unsigned long rv = -EIO;
-	unsigned long (*get_area)(struct file *, unsigned long, unsigned long,
-				  unsigned long, unsigned long) = NULL;
+
 	if (use_pde(pde)) {
+		typeof(proc_reg_get_unmapped_area) *get_area
 #ifdef CONFIG_MMU
-		get_area = current->mm->get_unmapped_area;
+			= pde->proc_fops->get_unmapped_area
+			  ?: current->mm->get_unmapped_area;
+#else
+			= pde->proc_fops->get_unmapped_area;
 #endif
-		if (pde->proc_fops->get_unmapped_area)
-			get_area = pde->proc_fops->get_unmapped_area;
-		if (get_area)
-			rv = get_area(file, orig_addr, len, pgoff, flags);
+
+		rv = get_area
+		     ? get_area(file, orig_addr, len, pgoff, flags)
+		     : orig_addr;
 		unuse_pde(pde);
 	}
 	return rv;
_

Patches currently in -mm which might be from JBeulich@xxxxxxxx are

procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case.patch
lib-decompress_unlz4c-always-set-an-error-return-code-on-failures.patch

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]