All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Williams, Dan J" <dan.j.williams@intel.com>
To: "hch@infradead.org" <hch@infradead.org>, "jack@suse.cz" <jack@suse.cz>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"darrick.wong@oracle.com" <darrick.wong@oracle.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"luto@kernel.org" <luto@kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"tytso@mit.edu" <tytso@mit.edu>, "arnd@arndb.de" <arnd@arndb.de>
Subject: Re: [PATCH 01/19] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags
Date: Sat, 14 Oct 2017 15:57:59 +0000	[thread overview]
Message-ID: <1507996677.21357.1.camel@intel.com> (raw)
In-Reply-To: <20171013071203.GA9105@infradead.org>

On Fri, 2017-10-13 at 00:12 -0700, Christoph Hellwig wrote:
> So did we settle on the new mmap_validate vs adding a new argument
> to ->mmap for real now?  I have to say I'd much prefer passing an
> additional argument instead, but if higher powers rule that out
> this version is ok.

Even if we decide to add a parameter to ->mmap() I think that should be
done after we merge this version. Otherwise there's no way to stage
these changes in advance of the merge window since we need to run the
"add parameter" coccinelle script near or after -rc1 when there's no
risk of new ->mmap() users being added.

> 
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 13dab191a23e..5aee97d64cae 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1701,6 +1701,8 @@ struct file_operations {
> >  	long (*unlocked_ioctl) (struct file *, unsigned int,
> > unsigned long);
> >  	long (*compat_ioctl) (struct file *, unsigned int,
> > unsigned long);
> >  	int (*mmap) (struct file *, struct vm_area_struct *);
> > +	int (*mmap_validate) (struct file *, struct vm_area_struct
> > *,
> > +			unsigned long);
> 
> Can we make this return a bool for ok vs not ok?  That way we only
> need to have the error code discussion in one place instead of every
> file system.

How about the following incremental update? It allows ->mmap_validate()
to be used as a full replacement for ->mmap() and it limits the error
code freedom to a centralized mmap_status_errno() routine:

---

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 5aee97d64cae..e07fcac17ba7 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1685,6 +1685,13 @@ struct block_device_operations;
 #define NOMMU_VMFLAGS \
 	(NOMMU_MAP_READ | NOMMU_MAP_WRITE | NOMMU_MAP_EXEC)
 
+enum mmap_status {
+	MMAP_SUCCESS,
+	MMAP_UNSUPPORTED_FLAGS,
+	MMAP_INVALID_FILE,
+	MMAP_RESOURCE_FAILURE,
+};
+typedef enum mmap_status mmap_status_t;
 
 struct iov_iter;
 
@@ -1701,7 +1708,7 @@ struct file_operations {
 	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
 	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
 	int (*mmap) (struct file *, struct vm_area_struct *);
-	int (*mmap_validate) (struct file *, struct vm_area_struct *,
+	mmap_status_t (*mmap_validate) (struct file *, struct vm_area_struct *,
 			unsigned long);
 	int (*open) (struct inode *, struct file *);
 	int (*flush) (struct file *, fl_owner_t id);
diff --git a/mm/mmap.c b/mm/mmap.c
index 2649c00581a0..c1b6a8c25ce7 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1432,7 +1432,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
 				vm_flags &= ~VM_MAYEXEC;
 			}
 
-			if (!file->f_op->mmap)
+			if (!file->f_op->mmap && !file->f_op->mmap_validate)
 				return -ENODEV;
 			if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
 				return -EINVAL;
@@ -1612,6 +1612,27 @@ static inline int accountable_mapping(struct file *file, vm_flags_t vm_flags)
 	return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE;
 }
 
+static int mmap_status_errno(mmap_status_t stat)
+{
+	static const int rc[] = {
+		[MMAP_SUCCESS] = 0,
+		[MMAP_UNSUPPORTED_FLAGS] = -EOPNOTSUPP,
+		[MMAP_INVALID_FILE] = -ENOTTY,
+		[MMAP_RESOURCE_FAILURE] = -ENOMEM,
+	};
+
+	switch (stat) {
+	case MMAP_SUCCESS:
+	case MMAP_UNSUPPORTED_FLAGS:
+	case MMAP_INVALID_FILE:
+	case MMAP_RESOURCE_FAILURE:
+		return rc[stat];
+	default:
+		/* unknown mmap_status */
+		return rc[MMAP_UNSUPPORTED_FLAGS];
+	}
+}
+
 unsigned long mmap_region(struct file *file, unsigned long addr,
 		unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
 		struct list_head *uf, unsigned long map_flags)
@@ -1619,6 +1640,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 	struct mm_struct *mm = current->mm;
 	struct vm_area_struct *vma, *prev;
 	int error;
+	mmap_status_t status;
 	struct rb_node **rb_link, *rb_parent;
 	unsigned long charged = 0;
 
@@ -1697,11 +1719,19 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 		 * vma_link() below can deny write-access if VM_DENYWRITE is set
 		 * and map writably if VM_SHARED is set. This usually means the
 		 * new file must not have been exposed to user-space, yet.
+		 *
+		 * We require ->mmap_validate in the MAP_SHARED_VALIDATE
+		 * case, prefer ->mmap_validate over ->mmap, and
+		 * otherwise fallback to legacy ->mmap.
 		 */
 		vma->vm_file = get_file(file);
-		if ((map_flags & MAP_TYPE) == MAP_SHARED_VALIDATE)
-			error = file->f_op->mmap_validate(file, vma, map_flags);
-		else
+		if ((map_flags & MAP_TYPE) == MAP_SHARED_VALIDATE) {
+			status = file->f_op->mmap_validate(file, vma, map_flags);
+			error = mmap_status_errno(status);
+		} else if (file->f_op->mmap_validate) {
+			status = file->f_op->mmap_validate(file, vma, map_flags);
+			error = mmap_status_errno(status);
+		} else
 			error = call_mmap(file, vma);
 		if (error)
 			goto unmap_and_free_vma;

  parent reply	other threads:[~2017-10-14 15:58 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 20:05 [PATCH 0/19 v3] dax, ext4, xfs: Synchronous page faults Jan Kara
2017-10-11 20:05 ` Jan Kara
2017-10-11 20:05 ` [PATCH 01/19] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13  7:12   ` Christoph Hellwig
2017-10-13 15:44     ` Dan Williams
2017-10-13 18:28       ` Dan Williams
2017-10-14 15:57     ` Williams, Dan J [this message]
2017-10-16  7:45       ` hch
2017-10-17 11:50         ` Jan Kara
2017-10-17 19:38           ` Dan Williams
2017-10-18  6:59           ` hch
2017-10-11 20:05 ` [PATCH 02/19] mm: Remove VM_FAULT_HWPOISON_LARGE_MASK Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 03/19] dax: Simplify arguments of dax_insert_mapping() Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 04/19] dax: Factor out getting of pfn out of iomap Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 05/19] dax: Create local variable for VMA in dax_iomap_pte_fault() Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 06/19] dax: Create local variable for vmf->flags & FAULT_FLAG_WRITE test Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 07/19] dax: Inline dax_insert_mapping() into the callsite Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 08/19] dax: Inline dax_pmd_insert_mapping() " Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 09/19] dax: Fix comment describing dax_iomap_fault() Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 10/19] dax: Allow dax_iomap_fault() to return pfn Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-11 20:05 ` [PATCH 11/19] dax: Allow tuning whether dax_insert_mapping_entry() dirties entry Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13  7:12   ` Christoph Hellwig
2017-10-13 19:26   ` Ross Zwisler
2017-10-11 20:05 ` [PATCH 12/19] mm: Define MAP_SYNC and VM_SYNC flags Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13  7:12   ` Christoph Hellwig
2017-10-13 19:44   ` Ross Zwisler
2017-10-16 15:37     ` Jan Kara
2017-10-11 20:05 ` [PATCH 13/19] dax, iomap: Add support for synchronous faults Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13  7:14   ` Christoph Hellwig
2017-10-11 20:05 ` [PATCH 14/19] dax: Implement dax_finish_sync_fault() Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13  7:21   ` Christoph Hellwig
2017-10-16 15:43     ` Jan Kara
2017-10-13 20:06   ` Ross Zwisler
2017-10-11 20:05 ` [PATCH 15/19] ext4: Simplify error handling in ext4_dax_huge_fault() Jan Kara
2017-10-11 20:05   ` Jan Kara
2017-10-13 20:09   ` Ross Zwisler
2017-10-11 20:06 ` [PATCH 16/19] ext4: Support for synchronous DAX faults Jan Kara
2017-10-11 20:06   ` Jan Kara
2017-10-11 22:23   ` Dan Williams
2017-10-12 13:42     ` Jan Kara
2017-10-13 20:58   ` Ross Zwisler
2017-10-16 15:50     ` Jan Kara
2017-10-11 20:06 ` [PATCH 17/19] ext4: Add support for MAP_SYNC flag Jan Kara
2017-10-11 20:06   ` Jan Kara
2017-10-11 22:11   ` Dan Williams
2017-10-12 13:42     ` Jan Kara
2017-10-13  0:23       ` Dan Williams
2017-10-13  7:22     ` Christoph Hellwig
2017-10-13 15:52       ` Dan Williams
2017-10-17 11:30         ` Jan Kara
2017-10-13  7:21   ` Christoph Hellwig
2017-10-16 15:14     ` Jan Kara
2017-10-11 20:06 ` [PATCH 18/19] xfs: support for synchronous DAX faults Jan Kara
2017-10-11 20:06   ` Jan Kara
2017-10-11 20:06 ` [PATCH 19/19] xfs: Add support for MAP_SYNC flag Jan Kara
2017-10-11 20:06   ` Jan Kara
2017-10-11 22:54   ` Dan Williams
2017-10-11 23:02   ` Dan Williams
2017-10-13  7:28   ` Christoph Hellwig
2017-10-11 21:18 ` [PATCH 0/19 v3] dax, ext4, xfs: Synchronous page faults Dan Williams
2017-10-11 22:43   ` Dave Chinner
2017-10-12  1:18     ` Dan Williams
2017-10-13 22:53     ` Ross Zwisler
2017-10-16 15:12       ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507996677.21357.1.camel@intel.com \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.