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
On Tue, 30 Oct 2007, Jeff Mahoney wrote:
>
> 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.
Hmm.. I think it's kind of stupid adding that special case early on, just
to get one particular error case return when there are multiple possible
ones.
I don't care deeply, but this does smell like a test issue rather than a
code issue.
Looking at that path, there are *other* things that might be worth
cleaning up, but this wasn't one of them..
Linus
---
diff --git a/mm/mmap.c b/mm/mmap.c
index facc1a7..fe286f7 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -893,7 +893,6 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,
unsigned long flags, unsigned long pgoff)
{
struct mm_struct * mm = current->mm;
- struct inode *inode;
unsigned int vm_flags;
int error;
int accountable = 1;
@@ -959,9 +958,9 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,
return -EAGAIN;
}
- inode = file ? file->f_path.dentry->d_inode : NULL;
-
if (file) {
+ struct inode *inode = file->f_path.dentry->d_inode;
+
switch (flags & MAP_TYPE) {
case MAP_SHARED:
if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE))
On Tue, 30 Oct 2007 15:45:56 -0700 (PDT) Linus Torvalds wrote:
>
>
> On Tue, 30 Oct 2007, Jeff Mahoney wrote:
> >
> > 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.
>
> Hmm.. I think it's kind of stupid adding that special case early on, just
> to get one particular error case return when there are multiple possible
> ones.
>
> I don't care deeply, but this does smell like a test issue rather than a
> code issue.
>
> Looking at that path, there are *other* things that might be worth
> cleaning up, but this wasn't one of them..
Jeff, will you (at least) notify the LTP project of this issue and
need for a patch?
Thanks.
> ---
> diff --git a/mm/mmap.c b/mm/mmap.c
> index facc1a7..fe286f7 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -893,7 +893,6 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,
> unsigned long flags, unsigned long pgoff)
> {
> struct mm_struct * mm = current->mm;
> - struct inode *inode;
> unsigned int vm_flags;
> int error;
> int accountable = 1;
> @@ -959,9 +958,9 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,
> return -EAGAIN;
> }
>
> - inode = file ? file->f_path.dentry->d_inode : NULL;
> -
> if (file) {
> + struct inode *inode = file->f_path.dentry->d_inode;
> +
> switch (flags & MAP_TYPE) {
> case MAP_SHARED:
> if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE))
> -
---
~Randy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Randy Dunlap wrote:
> On Tue, 30 Oct 2007 15:45:56 -0700 (PDT) Linus Torvalds wrote:
>
>>
>> On Tue, 30 Oct 2007, Jeff Mahoney wrote:
>>> 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.
>> Hmm.. I think it's kind of stupid adding that special case early on, just
>> to get one particular error case return when there are multiple possible
>> ones.
>>
>> I don't care deeply, but this does smell like a test issue rather than a
>> code issue.
>>
>> Looking at that path, there are *other* things that might be worth
>> cleaning up, but this wasn't one of them..
>
>
> Jeff, will you (at least) notify the LTP project of this issue and
> need for a patch?
Sure. I'll send that out tonight or tomorrow morning.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHJ9U5LPWxlyuTD7IRArcqAJ4hGnSf0Z67sLJJ6OU4t72VFodPnQCbBwHw
Usml2lnHxuwyXpXvjwlTbaI=
=ss6E
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 30 Oct 2007, Jeff Mahoney wrote:
>> 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.
>
> Hmm.. I think it's kind of stupid adding that special case early on, just
> to get one particular error case return when there are multiple possible
> ones.
>
> I don't care deeply, but this does smell like a test issue rather than a
> code issue.
Ok, I'll drop it and send the LTP fix upstream there.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHJ9VkLPWxlyuTD7IRAviiAKCcOhYu2joLm8tPWZDgMa/5uvtqGQCgiz0Y
z3fHhkTg1Vfqsw9WDadHOak=
=bItr
-----END PGP SIGNATURE-----