Commit 80c5606c3b45e0176c32d3108ade1e1cb0b954f3 from Linus moved the
VM_MAYEXEC code further down, but in the process broke the mmap_23_1
test from the LTP suite.
Moving it down means that the test for FMODE_READ ends up above
the test for f_op->mmap. If the write side of the pipe is called for
mmap(), we end up returning -EACCES rather than -ENODEV. Was this
an intended change of behavior? Unless there's a global error precedence
in SuS that I missed, I think both error codes could be valid here,
but it is a difference in behavior. Do any spec gurus know for certain?
Personally, I think this is probably a case of LTP codifying existing
behavior rather than testing the for the specification. If that's the case
and nobody really cares about the change in behavior, I'm fine letting this
drop.
Signed-off-by: Jeff Mahoney <[email protected]>
---
mm/mmap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/mm/mmap.c 2007-10-12 20:43:48.000000000 -0400
+++ b/mm/mmap.c 2007-10-23 15:44:45.000000000 -0400
@@ -900,6 +900,9 @@
int accountable = 1;
unsigned long reqprot = prot;
+ if (file && (!file->f_op || !file->f_op->mmap))
+ return -ENODEV;
+
/*
* Does the application expect PROT_READ to imply PROT_EXEC?
*
@@ -997,8 +1000,6 @@
if (is_file_hugepages(file))
accountable = 0;
- if (!file->f_op || !file->f_op->mmap)
- return -ENODEV;
break;
default:
--
Jeff Mahoney
SUSE Labs
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
