diff options
author | Jan Beulich <JBeulich@suse.com> | 2013-12-13 05:12:22 +0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2013-12-13 06:19:26 +0400 |
commit | ae5758a1a7b7bdfdcfaf2d78a5a0f8675149dd79 (patch) | |
tree | 724d6af0adf51da4e34c09bb66c9586f0de945b6 /fs/namespace.c | |
parent | a0d8b00a3381f9d75764b3377590451cb0b4fe41 (diff) | |
download | linux-ae5758a1a7b7bdfdcfaf2d78a5a0f8675149dd79.tar.xz |
procfs: also fix proc_reg_get_unmapped_area() for !MMU case
Commit fad1a86e25e0 ("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 fad1a86e25e0 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@suse.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> [3.12.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/namespace.c')
0 files changed, 0 insertions, 0 deletions