All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Matthew Wilcox <willy@infradead.org>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, 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: Sat, 25 Nov 2017 19:45:21 +0100	[thread overview]
Message-ID: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> (raw)
In-Reply-To: <20171122195318.GA29485@bombadil.infradead.org>

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/

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: Helge Deller <deller@gmx.de>
To: Matthew Wilcox <willy@infradead.org>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, 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: Sat, 25 Nov 2017 19:45:21 +0100	[thread overview]
Message-ID: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> (raw)
In-Reply-To: <20171122195318.GA29485@bombadil.infradead.org>

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/

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

  reply	other threads:[~2017-11-25 18:45 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 [this message]
2017-11-25 18:45           ` Helge Deller
2017-11-27 15:55           ` Vlastimil Babka
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=09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de \
    --to=deller@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --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=vbabka@suse.cz \
    --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: 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.