From: Jan Kara <jack@suse.cz> To: Dan Williams <dan.j.williams@intel.com> Cc: darrick.wong@oracle.com, Jan Kara <jack@suse.cz>, Arnd Bergmann <arnd@arndb.de>, linux-nvdimm@lists.01.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags Date: Tue, 15 Aug 2017 14:27:01 +0200 [thread overview] Message-ID: <20170815122701.GF27505@quack2.suse.cz> (raw) In-Reply-To: <150277753660.23945.11500026891611444016.stgit@dwillia2-desk3.amr.corp.intel.com> On Mon 14-08-17 23:12:16, Dan Williams wrote: > The mmap syscall suffers from the ABI anti-pattern of not validating > unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a > mechanism to define new behavior that is known to fail on older kernels > without the feature. Use the fact that specifying MAP_SHARED and > MAP_PRIVATE at the same time is invalid as a cute hack to allow a new > set of validated flags to be introduced. > > This also introduces the ->fmmap() file operation that is ->mmap() plus > flags. Each ->fmmap() implementation must fail requests when a locally > unsupported flag is specified. ... > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 1104e5df39ef..bbe755d0caee 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1674,6 +1674,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 (*fmmap) (struct file *, struct vm_area_struct *, unsigned long); > int (*open) (struct inode *, struct file *); > int (*flush) (struct file *, fl_owner_t id); > int (*release) (struct inode *, struct file *); > @@ -1748,6 +1749,12 @@ static inline int call_mmap(struct file *file, struct vm_area_struct *vma) > return file->f_op->mmap(file, vma); > } > > +static inline int call_fmmap(struct file *file, struct vm_area_struct *vma, > + unsigned long flags) > +{ > + return file->f_op->fmmap(file, vma, flags); > +} > + Hum, I dislike a new file op for this when the only problem with ->mmap is that it misses 'flags' argument. I understand there are lots of ->mmap implementations out there and modifying prototype of them all is painful but is it so bad? Coccinelle patch for this should be rather easy... Also for MAP_SYNC I want the flag to be copied in VMA anyway so for that I don't need additional flags argument anyway. And I wonder how you want to make things work without VMA flag in case of MAP_DIRECT as well - VMAs can be split, partially unmapped etc. and so without VMA flag you are going to have hard time to detect whether there's any mapping left which blocks block mapping changes. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz> To: Dan Williams <dan.j.williams@intel.com> Cc: darrick.wong@oracle.com, Jan Kara <jack@suse.cz>, Arnd Bergmann <arnd@arndb.de>, linux-nvdimm@lists.01.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags Date: Tue, 15 Aug 2017 14:27:01 +0200 [thread overview] Message-ID: <20170815122701.GF27505@quack2.suse.cz> (raw) In-Reply-To: <150277753660.23945.11500026891611444016.stgit@dwillia2-desk3.amr.corp.intel.com> On Mon 14-08-17 23:12:16, Dan Williams wrote: > The mmap syscall suffers from the ABI anti-pattern of not validating > unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a > mechanism to define new behavior that is known to fail on older kernels > without the feature. Use the fact that specifying MAP_SHARED and > MAP_PRIVATE at the same time is invalid as a cute hack to allow a new > set of validated flags to be introduced. > > This also introduces the ->fmmap() file operation that is ->mmap() plus > flags. Each ->fmmap() implementation must fail requests when a locally > unsupported flag is specified. ... > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 1104e5df39ef..bbe755d0caee 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1674,6 +1674,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 (*fmmap) (struct file *, struct vm_area_struct *, unsigned long); > int (*open) (struct inode *, struct file *); > int (*flush) (struct file *, fl_owner_t id); > int (*release) (struct inode *, struct file *); > @@ -1748,6 +1749,12 @@ static inline int call_mmap(struct file *file, struct vm_area_struct *vma) > return file->f_op->mmap(file, vma); > } > > +static inline int call_fmmap(struct file *file, struct vm_area_struct *vma, > + unsigned long flags) > +{ > + return file->f_op->fmmap(file, vma, flags); > +} > + Hum, I dislike a new file op for this when the only problem with ->mmap is that it misses 'flags' argument. I understand there are lots of ->mmap implementations out there and modifying prototype of them all is painful but is it so bad? Coccinelle patch for this should be rather easy... Also for MAP_SYNC I want the flag to be copied in VMA anyway so for that I don't need additional flags argument anyway. And I wonder how you want to make things work without VMA flag in case of MAP_DIRECT as well - VMAs can be split, partially unmapped etc. and so without VMA flag you are going to have hard time to detect whether there's any mapping left which blocks block mapping changes. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
next prev parent reply other threads:[~2017-08-15 12:27 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-15 6:12 [PATCH v4 0/3] MAP_DIRECT and block-map sealed files Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` [PATCH v4 1/3] fs, xfs: introduce S_IOMAP_SEALED Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 12:27 ` Jan Kara [this message] 2017-08-15 12:27 ` Jan Kara 2017-08-15 16:24 ` Dan Williams 2017-08-15 16:24 ` Dan Williams 2017-08-15 16:24 ` Dan Williams 2017-08-15 16:24 ` Dan Williams 2017-09-17 3:44 ` Dan Williams 2017-09-17 3:44 ` Dan Williams 2017-09-17 3:44 ` Dan Williams 2017-09-17 17:39 ` Christoph Hellwig 2017-09-17 17:39 ` Christoph Hellwig 2017-09-17 17:39 ` Christoph Hellwig 2017-09-18 9:31 ` Jan Kara 2017-09-18 9:31 ` Jan Kara 2017-09-18 9:31 ` Jan Kara 2017-09-18 9:31 ` Jan Kara 2017-09-18 15:47 ` Dan Williams 2017-09-18 15:47 ` Dan Williams 2017-09-18 9:26 ` Jan Kara 2017-09-18 9:26 ` Jan Kara 2017-09-18 9:26 ` Jan Kara 2017-08-15 16:28 ` Andy Lutomirski 2017-08-15 16:28 ` Andy Lutomirski 2017-08-15 16:28 ` Andy Lutomirski 2017-08-15 22:31 ` Dan Williams 2017-08-15 22:31 ` Dan Williams 2017-08-17 8:06 ` kbuild test robot 2017-08-17 8:06 ` kbuild test robot 2017-08-15 6:12 ` [PATCH v4 3/3] fs, xfs: introduce MAP_DIRECT for creating block-map-sealed file ranges Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 6:12 ` Dan Williams 2017-08-15 9:18 ` Kirill A. Shutemov 2017-08-15 9:18 ` Kirill A. Shutemov 2017-08-15 9:18 ` Kirill A. Shutemov 2017-08-15 17:11 ` Dan Williams 2017-08-15 17:11 ` Dan Williams 2017-08-15 17:11 ` Dan Williams 2017-08-16 10:25 ` Kirill A. Shutemov 2017-08-16 10:25 ` Kirill A. Shutemov 2017-08-16 10:25 ` Kirill A. Shutemov 2017-08-15 12:42 ` Jan Kara 2017-08-15 12:42 ` Jan Kara 2017-08-15 12:42 ` Jan Kara 2017-08-15 16:29 ` Dan Williams 2017-08-15 16:29 ` Dan Williams 2017-08-15 16:29 ` Dan Williams 2017-08-15 16:29 ` Dan Williams 2017-08-16 1:15 ` Dan Williams 2017-08-16 1:15 ` Dan Williams 2017-08-16 1:15 ` Dan Williams 2017-08-16 1:15 ` Dan Williams 2017-08-17 8:49 ` kbuild test robot 2017-08-17 8:49 ` kbuild test robot 2017-08-17 8:49 ` kbuild test robot 2017-08-15 9:01 ` [PATCH v4 0/3] MAP_DIRECT and block-map sealed files Dave Chinner 2017-08-15 9:01 ` Dave Chinner 2017-08-15 9:01 ` Dave Chinner
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=20170815122701.GF27505@quack2.suse.cz \ --to=jack@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=dan.j.williams@intel.com \ --cc=darrick.wong@oracle.com \ --cc=hch@lst.de \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-xfs@vger.kernel.org \ --cc=luto@kernel.org \ /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: linkBe 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.