mmap: restore -ENODEV on missing f_op->mmap

PATCH In review Jeff Mahoney 3 participants 5 messages Oct 30, 2007 – Oct 31, 2007

Subsystems (2)

Memory management Memory mapping

lore

Share & tools

lore

Jeff Mahoney

author

2007-10-30 22:17 UTC #0 lore raw

PATCH 1/1 mmap: restore -ENODEV on missing f_op->mmap

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

mm/mmap.c +3 -2

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

Signature · 2 lines

Jeff Mahoney
SUSE Labs

Linus Torvalds

2007-10-30 22:46 UTC #1 lore raw

Quoted 5 lines · Jeff Mahoney

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

---

mm/mmap.c +2 -3

index facc1a7..fe286f7 100644
@@ -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 Dunlap

2007-10-30 23:14 UTC #2 lore raw

Quoted 13 lines · On Tue, 30 Oct 2007 15:45:56 -0700 (PDT) Linus Torvalds wrote:

Quoted 5 lines · Jeff Mahoney
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.

Quoted 5 lines

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.

Quoted 16 lines

---

mm/mmap.c +0 -1

index facc1a7..fe286f7 100644
@@ -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;
 	}

mm/mmap.c unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,

Quoted 10 lines

mm/mmap.c +2 -3

 
-	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

Jeff Mahoney

author

2007-10-31 01:03 UTC #3 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 15 lines · Randy Dunlap

Quoted 13 lines · On Tue, 30 Oct 2007 15:45:56 -0700 (PDT) Linus Torvalds wrote:
Quoted 4 lines · Jeff Mahoney
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.

Quoted 6 lines

Quoted 2 lines
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-----

Jeff Mahoney

author

2007-10-31 01:04 UTC #4 lore raw

In reply to Linus Torvalds

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Linus Torvalds

Quoted 4 lines · Jeff Mahoney
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.

Quoted 6 lines

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