[PATCH] mmap: restore -ENODEV on missing f_op->mmap

[PATCH] mmap: restore -ENODEV on missing f_op->mmap

[Jeff Mahoney]

 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 <jeffm@suse.com>

---

 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

Re: [PATCH] mmap: restore -ENODEV on missing f_op->mmap

[Linus Torvalds]

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))

Re: [PATCH] mmap: restore -ENODEV on missing f_op->mmap

[Randy Dunlap]

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

Re: [PATCH] mmap: restore -ENODEV on missing f_op->mmap

[Jeff Mahoney]

-----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-----

Re: [PATCH] mmap: restore -ENODEV on missing f_op->mmap

[Jeff Mahoney]

-----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-----