From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
hch-jcswGhMUV9g@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags
Date: Mon, 11 Sep 2017 13:10:30 +0200 [thread overview]
Message-ID: <20170911111030.GA20127@lst.de> (raw)
In-Reply-To: <20170911094714.GD8503-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote:
> On Fri 08-09-17 12:35:13, Dan Williams wrote:
> > The mmap(2) 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 support. Define a new MAP_SHARED_VALIDATE flag pattern that
> > is guaranteed to fail on all legacy mmap implementations.
> >
> > With this in place new flags can be defined as:
> >
> > #define MAP_new (MAP_SHARED_VALIDATE | val)
>
> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> type, I'd expect we define new flags just as any other mapping flags...
> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.
Btw, I still think it should be a new hidden flag and not a new mapping
type. I brought this up last time, so maybe I missed the answer
to my concern.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>,
torvalds@linux-foundation.org, Arnd Bergmann <arnd@arndb.de>,
linux-nvdimm@lists.01.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
hch@lst.de
Subject: Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags
Date: Mon, 11 Sep 2017 13:10:30 +0200 [thread overview]
Message-ID: <20170911111030.GA20127@lst.de> (raw)
In-Reply-To: <20170911094714.GD8503@quack2.suse.cz>
On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote:
> On Fri 08-09-17 12:35:13, Dan Williams wrote:
> > The mmap(2) 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 support. Define a new MAP_SHARED_VALIDATE flag pattern that
> > is guaranteed to fail on all legacy mmap implementations.
> >
> > With this in place new flags can be defined as:
> >
> > #define MAP_new (MAP_SHARED_VALIDATE | val)
>
> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> type, I'd expect we define new flags just as any other mapping flags...
> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.
Btw, I still think it should be a new hidden flag and not a new mapping
type. I brought this up last time, so maybe I missed the answer
to my concern.
--
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: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>,
torvalds@linux-foundation.org, Arnd Bergmann <arnd@arndb.de>,
linux-nvdimm@lists.01.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
hch@lst.de
Subject: Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags
Date: Mon, 11 Sep 2017 13:10:30 +0200 [thread overview]
Message-ID: <20170911111030.GA20127@lst.de> (raw)
In-Reply-To: <20170911094714.GD8503@quack2.suse.cz>
On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote:
> On Fri 08-09-17 12:35:13, Dan Williams wrote:
> > The mmap(2) 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 support. Define a new MAP_SHARED_VALIDATE flag pattern that
> > is guaranteed to fail on all legacy mmap implementations.
> >
> > With this in place new flags can be defined as:
> >
> > #define MAP_new (MAP_SHARED_VALIDATE | val)
>
> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> type, I'd expect we define new flags just as any other mapping flags...
> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.
Btw, I still think it should be a new hidden flag and not a new mapping
type. I brought this up last time, so maybe I missed the answer
to my concern.
next prev parent reply other threads:[~2017-09-11 11:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 19:35 [RFC PATCH v8 0/2] mmap: safely enable support for new flags Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-08 19:35 ` Dan Williams
[not found] ` <150489930202.29460.5141541423730649272.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-09-08 19:35 ` [RFC PATCH v8 1/2] vfs: add flags parameter to all ->mmap() handlers Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-11 9:50 ` Jan Kara
2017-09-11 9:50 ` Jan Kara
2017-09-11 9:50 ` Jan Kara
2017-09-08 19:35 ` [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-08 19:35 ` Dan Williams
2017-09-08 19:35 ` Dan Williams
[not found] ` <150489931339.29460.8760855724603300792.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-09-11 9:47 ` Jan Kara
2017-09-11 9:47 ` Jan Kara
2017-09-11 9:47 ` Jan Kara
2017-09-11 9:47 ` Jan Kara
[not found] ` <20170911094714.GD8503-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-09-11 11:10 ` Christoph Hellwig [this message]
2017-09-11 11:10 ` Christoph Hellwig
2017-09-11 11:10 ` Christoph Hellwig
[not found] ` <20170911111030.GA20127-jcswGhMUV9g@public.gmane.org>
2017-09-11 11:45 ` Jan Kara
2017-09-11 11:45 ` Jan Kara
2017-09-11 11:45 ` Jan Kara
2017-09-11 11:45 ` Jan Kara
2017-09-11 17:01 ` Dan Williams
2017-09-11 17:01 ` Dan Williams
2017-09-11 17:01 ` Dan Williams
2017-09-11 17:21 ` Dan Williams
2017-09-11 17:21 ` Dan Williams
2017-09-11 17:21 ` Dan Williams
2017-09-11 17:21 ` Dan Williams
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=20170911111030.GA20127@lst.de \
--to=hch-jcswghmuv9g@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=jack-AlSwsSmVLrQ@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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.