Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1720396
| From | Dan Williams <dan.j.williams@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags |
| Date | 2017-08-25 22:30 +0200 |
| Message-ID | <uitoS-ek-11@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <uimx3-4tc-7@gated-at.bofh.it> <uipbz-5V8-7@gated-at.bofh.it> <uiplh-6dJ-41@gated-at.bofh.it> <uipuW-6gP-27@gated-at.bofh.it> <uipEB-6ki-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Aug 25, 2017 at 9:19 AM, Helge Deller <deller@gmx.de> wrote: > On 25.08.2017 18:16, Kirill A. Shutemov wrote: >> On Fri, Aug 25, 2017 at 09:02:36AM -0700, Christoph Hellwig wrote: >>> On Fri, Aug 25, 2017 at 06:58:03PM +0300, Kirill A. Shutemov wrote: >>>> Not all archs are ready for this: >>>> >>>> arch/parisc/include/uapi/asm/mman.h:#define MAP_TYPE 0x03 /* Mask for type of mapping */ >>>> arch/parisc/include/uapi/asm/mman.h:#define MAP_FIXED 0x04 /* Interpret addr exactly */ >>> >>> I'd be happy to say that we should not care about parisc for >>> persistent memory. We'll just have to find a way to exclude >>> parisc without making life too ugly. >> >> I don't think creapling mmap() interface for one arch is the right way to >> go. I think the interface should be universal. >> >> I may imagine MAP_DIRECT can be useful not only for persistent memory. >> For tmpfs instead of mlock()? > > On parisc we have > #define MAP_SHARED 0x01 /* Share changes */ > #define MAP_PRIVATE 0x02 /* Changes are private */ > #define MAP_TYPE 0x03 /* Mask for type of mapping */ > #define MAP_FIXED 0x04 /* Interpret addr exactly */ > #define MAP_ANONYMOUS 0x10 /* don't use a file */ > > So, if you need a MAP_DIRECT, wouldn't e.g. > #define MAP_DIRECT 0x08 > be possible (for parisc, and others 0x04). > And if MAP_TYPE needs to include this flag on parisc: > #define MAP_TYPE (0x03 | 0x08) /* Mask for type of mapping */ The problem here is that to support new the mmap flags the arch needs to find a flag that is guaranteed to fail on older kernels. Defining MAP_DIRECT to 0x8 on parisc doesn't work because it will simply be ignored on older parisc kernels. However, it's already the case that several archs have their own sys_mmap entry points. Those archs that can't follow the common scheme (only parsic it seems) will need to add a new mmap syscall. I think that's a reasonable tradeoff to allow every other architecture to add this support with their existing mmap syscall paths. That means MAP_DIRECT should be defined to MAP_TYPE on parisc until it later defines an opt-in mechanism to a new syscall that honors MAP_DIRECT as a valid flag.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
[PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Christoph Hellwig <hch@lst.de> - 2017-08-24 18:20 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Christoph Hellwig <hch@lst.de> - 2017-08-24 18:40 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 22:30 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 18:40 +0200
[PATCH v6 5/5] fs, fcntl: add F_MAP_DIRECT Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
[PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Jan Kara <jack@suse.cz> - 2017-08-24 15:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-24 19:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-24 19:40 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-25 15:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-25 18:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-25 18:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-25 18:20 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-25 18:30 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-08-25 19:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-25 22:30 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-26 09:50 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-26 17:20 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-26 22:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-27 00:50 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-27 02:00 +0200
[PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Christoph Hellwig <hch@lst.de> - 2017-08-24 18:20 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-25 08:10 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-25 21:50 +0200
Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Christoph Hellwig <hch@lst.de> - 2017-08-24 18:10 +0200
Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Dan Williams <dan.j.williams@intel.com> - 2017-08-24 18:30 +0200
Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations' Christoph Hellwig <hch@infradead.org> - 2017-08-24 19:00 +0200
Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations' Dan Williams <dan.j.williams@intel.com> - 2017-08-24 19:50 +0200
csiph-web