From: Vlastimil Babka <vbabka@suse.cz> To: Helge Deller <deller@gmx.de>, Matthew Wilcox <willy@infradead.org>, Dan Williams <dan.j.williams@intel.com> Cc: Jan Kara <jack@suse.cz>, Ross Zwisler <ross.zwisler@linux.intel.com>, Christoph Hellwig <hch@infradead.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>, Linux MM <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>, linux-ext4 <linux-ext4@vger.kernel.org>, linux-xfs <linux-xfs@vger.kernel.org>, "Darrick J . Wong" <darrick.wong@oracle.com>, Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, Kees Cook <keescook@chromium.org>, Florian Weimer <fweimer@redhat.com>, John Hubbard <jhubbard@nvidia.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, linux-parisc@vger.kernel.org Subject: Re: [PATCH 01/18] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Date: Mon, 27 Nov 2017 16:55:54 +0100 [thread overview] Message-ID: <35fa2cb6-9957-fd77-836c-760cecc64b2e@suse.cz> (raw) In-Reply-To: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> On 11/25/2017 07:45 PM, Helge Deller wrote: > On 22.11.2017 20:53, Matthew Wilcox wrote: >> On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote: >>> On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka <vbabka@suse.cz> wrote: >>>> On 11/01/2017 04:36 PM, Jan Kara wrote: >>>>> From: Dan Williams <dan.j.williams@intel.com> >>>>> >>>>> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >>>>> unknown flags. However, proposals like MAP_SYNC need a mechanism to >>>>> define new behavior that is known to fail on older kernels without the >>>>> support. Define a new MAP_SHARED_VALIDATE flag pattern that is >>>>> guaranteed to fail on all legacy mmap implementations. >>>> >>>> So I'm trying to make sense of this together with Michal's attempt for >>>> MAP_FIXED_SAFE [1] where he has to introduce a completely new flag >>>> instead of flag modifier exactly for the reason of not validating >>>> unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE >>>> implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a >>>> modifier cannot build on top of this. Wouldn't thus it be really better >>>> long-term to introduce mmap3 at this point? ... >>> >>> We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch >>> except parisc. Can we steal an extra bit for MAP_TYPE from somewhere >>> else on parisc? >> >> It looks like 0x08 should work. > > I posted an RFC to the parisc mailing list for that: > https://patchwork.kernel.org/patch/9970553/ Thanks. BTW there doesn't seem to be much interest making MAP_FIXED_SAFE a flag modifier after all, so MAP_PRIVATE_VALIDATE wouldn't get immediate users. > Basically this is (for parisc only): > -#define MAP_TYPE 0x03 /* Mask for type of mapping */ > +#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */ > #define MAP_FIXED 0x04 /* Interpret addr exactly */ > +#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */ > #define MAP_ANONYMOUS 0x10 /* don't use a file */ > +#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */ > >> But I don't have an HPUX machine around >> to check that HP didn't use that bit for something else. > > We completely dropped support for HPUX binaries, so it's not relvant any longer. > >> It'd probably help to cc the linux-parisc mailing list when asking >> questions about PARISC, eh? > > Yes, please. > > Helge > -- 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: Vlastimil Babka <vbabka@suse.cz> To: Helge Deller <deller@gmx.de>, Matthew Wilcox <willy@infradead.org>, Dan Williams <dan.j.williams@intel.com> Cc: Jan Kara <jack@suse.cz>, Ross Zwisler <ross.zwisler@linux.intel.com>, Christoph Hellwig <hch@infradead.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>, Linux MM <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>, linux-ext4 <linux-ext4@vger.kernel.org>, linux-xfs <linux-xfs@vger.kernel.org>, "Darrick J . Wong" <darrick.wong@oracle.com>, Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, Kees Cook <keescook@chromium.org>, Florian Weimer <fweimer@redhat.com>, John Hubbard <jhubbard@nvidia.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, linux-parisc@vger.kernel.org Subject: Re: [PATCH 01/18] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Date: Mon, 27 Nov 2017 16:55:54 +0100 [thread overview] Message-ID: <35fa2cb6-9957-fd77-836c-760cecc64b2e@suse.cz> (raw) In-Reply-To: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> On 11/25/2017 07:45 PM, Helge Deller wrote: > On 22.11.2017 20:53, Matthew Wilcox wrote: >> On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote: >>> On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka <vbabka@suse.cz> wrote: >>>> On 11/01/2017 04:36 PM, Jan Kara wrote: >>>>> From: Dan Williams <dan.j.williams@intel.com> >>>>> >>>>> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >>>>> unknown flags. However, proposals like MAP_SYNC need a mechanism to >>>>> define new behavior that is known to fail on older kernels without the >>>>> support. Define a new MAP_SHARED_VALIDATE flag pattern that is >>>>> guaranteed to fail on all legacy mmap implementations. >>>> >>>> So I'm trying to make sense of this together with Michal's attempt for >>>> MAP_FIXED_SAFE [1] where he has to introduce a completely new flag >>>> instead of flag modifier exactly for the reason of not validating >>>> unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE >>>> implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a >>>> modifier cannot build on top of this. Wouldn't thus it be really better >>>> long-term to introduce mmap3 at this point? ... >>> >>> We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch >>> except parisc. Can we steal an extra bit for MAP_TYPE from somewhere >>> else on parisc? >> >> It looks like 0x08 should work. > > I posted an RFC to the parisc mailing list for that: > https://patchwork.kernel.org/patch/9970553/ Thanks. BTW there doesn't seem to be much interest making MAP_FIXED_SAFE a flag modifier after all, so MAP_PRIVATE_VALIDATE wouldn't get immediate users. > Basically this is (for parisc only): > -#define MAP_TYPE 0x03 /* Mask for type of mapping */ > +#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */ > #define MAP_FIXED 0x04 /* Interpret addr exactly */ > +#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */ > #define MAP_ANONYMOUS 0x10 /* don't use a file */ > +#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */ > >> But I don't have an HPUX machine around >> to check that HP didn't use that bit for something else. > > We completely dropped support for HPUX binaries, so it's not relvant any longer. > >> It'd probably help to cc the linux-parisc mailing list when asking >> questions about PARISC, eh? > > Yes, please. > > Helge >
next prev parent reply other threads:[~2017-11-27 15:55 UTC|newest] Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-01 15:36 [PATCH 0/18 v6] dax, ext4, xfs: Synchronous page faults Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 01/18] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-22 12:02 ` Vlastimil Babka 2017-11-22 12:02 ` Vlastimil Babka 2017-11-22 12:02 ` Vlastimil Babka 2017-11-22 12:02 ` Vlastimil Babka 2017-11-22 16:52 ` Dan Williams 2017-11-22 16:52 ` Dan Williams 2017-11-22 16:52 ` Dan Williams 2017-11-22 19:53 ` Matthew Wilcox 2017-11-22 19:53 ` Matthew Wilcox 2017-11-22 19:53 ` Matthew Wilcox 2017-11-22 19:53 ` Matthew Wilcox 2017-11-25 18:45 ` Helge Deller 2017-11-25 18:45 ` Helge Deller 2017-11-27 15:55 ` Vlastimil Babka [this message] 2017-11-27 15:55 ` Vlastimil Babka 2017-11-01 15:36 ` [PATCH 02/18] mm: Remove VM_FAULT_HWPOISON_LARGE_MASK Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 03/18] dax: Simplify arguments of dax_insert_mapping() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 04/18] dax: Factor out getting of pfn out of iomap Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 05/18] dax: Create local variable for VMA in dax_iomap_pte_fault() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 06/18] dax: Create local variable for vmf->flags & FAULT_FLAG_WRITE test Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 07/18] dax: Inline dax_insert_mapping() into the callsite Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 08/18] dax: Inline dax_pmd_insert_mapping() " Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 09/18] dax: Fix comment describing dax_iomap_fault() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 10/18] dax: Allow dax_iomap_fault() to return pfn Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 11/18] dax: Allow tuning whether dax_insert_mapping_entry() dirties entry Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 12/18] mm: Define MAP_SYNC and VM_SYNC flags Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 13/18] dax, iomap: Add support for synchronous faults Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 14/18] dax: Implement dax_finish_sync_fault() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 15/18] ext4: Simplify error handling in ext4_dax_huge_fault() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 16/18] ext4: Support for synchronous DAX faults Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` [PATCH 17/18] xfs: Implement xfs_filemap_pfn_mkwrite() using __xfs_filemap_fault() Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-14 2:19 ` Darrick J. Wong 2017-11-14 2:19 ` Darrick J. Wong 2017-11-14 2:19 ` Darrick J. Wong 2017-11-14 2:19 ` Darrick J. Wong 2017-11-01 15:36 ` [PATCH 18/18] xfs: support for synchronous DAX faults Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-14 2:19 ` Darrick J. Wong 2017-11-14 2:19 ` Darrick J. Wong 2017-11-01 15:36 ` [PATCH] mmap.2: Add description of MAP_SHARED_VALIDATE and MAP_SYNC Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2017-11-01 15:36 ` Jan Kara 2018-04-12 13:00 ` Michael Kerrisk (man-pages) 2018-04-12 13:00 ` Michael Kerrisk (man-pages) 2018-04-12 13:00 ` Michael Kerrisk (man-pages) 2018-04-12 14:00 ` Ross Zwisler 2018-04-12 14:00 ` Ross Zwisler 2018-04-12 14:22 ` Jan Kara 2018-04-12 14:22 ` Jan Kara 2018-04-12 14:22 ` Jan Kara 2018-04-12 18:20 ` Michael Kerrisk (man-pages) 2018-04-12 18:20 ` Michael Kerrisk (man-pages) 2018-04-12 18:20 ` Michael Kerrisk (man-pages) 2018-04-13 11:17 ` Jan Kara 2018-04-13 11:17 ` Jan Kara 2018-04-13 11:17 ` 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=35fa2cb6-9957-fd77-836c-760cecc64b2e@suse.cz \ --to=vbabka@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=dan.j.williams@intel.com \ --cc=darrick.wong@oracle.com \ --cc=deller@gmx.de \ --cc=fweimer@redhat.com \ --cc=hch@infradead.org \ --cc=jack@suse.cz \ --cc=jhubbard@nvidia.com \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-parisc@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mhocko@kernel.org \ --cc=ross.zwisler@linux.intel.com \ --cc=willy@infradead.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.