mmap.2: Add description of MAP_SHARED_VALIDATE and MAP_SYNC

Message ID 20171101153648.30166-20-jack@suse.cz
State Not Applicable
Headers show
Series
  • dax, ext4, xfs: Synchronous page faults
Related show

Commit Message

Jan Kara Nov. 1, 2017, 3:36 p.m.
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
 man2/mmap.2 | 35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

Comments

Michael Kerrisk (man-pages) April 12, 2018, 1 p.m. | #1
Hello Jan,

I have applied your patch, and tweaked the text a little, and pushed
the result to the git repo.

On 1 November 2017 at 16:36, Jan Kara <jack@suse.cz> wrote:
> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Jan Kara <jack@suse.cz>

I have a question below.

> ---
>  man2/mmap.2 | 35 ++++++++++++++++++++++++++++++++++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/man2/mmap.2 b/man2/mmap.2
> index 47c3148653be..b38ee6809327 100644
> --- a/man2/mmap.2
> +++ b/man2/mmap.2
> @@ -125,6 +125,21 @@ are carried through to the underlying file.
>  to the underlying file requires the use of
>  .BR msync (2).)
>  .TP
> +.BR MAP_SHARED_VALIDATE " (since Linux 4.15)"
> +The same as
> +.B MAP_SHARED
> +except that
> +.B MAP_SHARED
> +mappings ignore unknown flags in
> +.IR flags .
> +In contrast when creating mapping of
> +.B MAP_SHARED_VALIDATE
> +mapping type, the kernel verifies all passed flags are known and fails the
> +mapping with
> +.BR EOPNOTSUPP
> +otherwise. This mapping type is also required to be able to use some mapping
> +flags.
> +.TP
>  .B MAP_PRIVATE
>  Create a private copy-on-write mapping.
>  Updates to the mapping are not visible to other processes
> @@ -134,7 +149,10 @@ It is unspecified whether changes made to the file after the
>  .BR mmap ()
>  call are visible in the mapped region.
>  .PP
> -Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.
> +.B MAP_SHARED
> +and
> +.B MAP_PRIVATE
> +are described in POSIX.1-2001 and POSIX.1-2008.
>  .PP
>  In addition, zero or more of the following values can be ORed in
>  .IR flags :
> @@ -352,6 +370,21 @@ option.
>  Because of the security implications,
>  that option is normally enabled only on embedded devices
>  (i.e., devices where one has complete control of the contents of user memory).
> +.TP
> +.BR MAP_SYNC " (since Linux 4.15)"
> +This flags is available only with
> +.B MAP_SHARED_VALIDATE
> +mapping type. Mappings of
> +.B MAP_SHARED
> +type will silently ignore this flag.
> +This flag is supported only for files supporting DAX (direct mapping of persistent
> +memory). For other files, creating mapping with this flag results in
> +.B EOPNOTSUPP
> +error. Shared file mappings with this flag provide the guarantee that while
> +some memory is writeably mapped in the address space of the process, it will
> +be visible in the same file at the same offset even after the system crashes or
> +is rebooted. This allows users of such mappings to make data modifications
> +persistent in a more efficient way using appropriate CPU instructions.

It feels like there's a word missing/unclear wording in the previous
line, before "using". Without that word, the sentence feels a bit
ambiguous.

Should it be:

persistent in a more efficient way *through the use of* appropriate
CPU instructions.

or:

persistent in a more efficient way *than using* appropriate CPU instructions.

?

Is suspect the first is correct, but need to check.

Cheers,

Michael
Ross Zwisler April 12, 2018, 2 p.m. | #2
On Thu, Apr 12, 2018 at 03:00:49PM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Jan,
> 
> I have applied your patch, and tweaked the text a little, and pushed
> the result to the git repo.
> 
> On 1 November 2017 at 16:36, Jan Kara <jack@suse.cz> wrote:
> > Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Signed-off-by: Jan Kara <jack@suse.cz>
> 
> I have a question below.
> 
> > ---
> >  man2/mmap.2 | 35 ++++++++++++++++++++++++++++++++++-
> >  1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/man2/mmap.2 b/man2/mmap.2
> > index 47c3148653be..b38ee6809327 100644
> > --- a/man2/mmap.2
> > +++ b/man2/mmap.2
> > @@ -125,6 +125,21 @@ are carried through to the underlying file.
> >  to the underlying file requires the use of
> >  .BR msync (2).)
> >  .TP
> > +.BR MAP_SHARED_VALIDATE " (since Linux 4.15)"
> > +The same as
> > +.B MAP_SHARED
> > +except that
> > +.B MAP_SHARED
> > +mappings ignore unknown flags in
> > +.IR flags .
> > +In contrast when creating mapping of
> > +.B MAP_SHARED_VALIDATE
> > +mapping type, the kernel verifies all passed flags are known and fails the
> > +mapping with
> > +.BR EOPNOTSUPP
> > +otherwise. This mapping type is also required to be able to use some mapping
> > +flags.
> > +.TP
> >  .B MAP_PRIVATE
> >  Create a private copy-on-write mapping.
> >  Updates to the mapping are not visible to other processes
> > @@ -134,7 +149,10 @@ It is unspecified whether changes made to the file after the
> >  .BR mmap ()
> >  call are visible in the mapped region.
> >  .PP
> > -Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.
> > +.B MAP_SHARED
> > +and
> > +.B MAP_PRIVATE
> > +are described in POSIX.1-2001 and POSIX.1-2008.
> >  .PP
> >  In addition, zero or more of the following values can be ORed in
> >  .IR flags :
> > @@ -352,6 +370,21 @@ option.
> >  Because of the security implications,
> >  that option is normally enabled only on embedded devices
> >  (i.e., devices where one has complete control of the contents of user memory).
> > +.TP
> > +.BR MAP_SYNC " (since Linux 4.15)"
> > +This flags is available only with
> > +.B MAP_SHARED_VALIDATE
> > +mapping type. Mappings of
> > +.B MAP_SHARED
> > +type will silently ignore this flag.
> > +This flag is supported only for files supporting DAX (direct mapping of persistent
> > +memory). For other files, creating mapping with this flag results in
> > +.B EOPNOTSUPP
> > +error. Shared file mappings with this flag provide the guarantee that while
> > +some memory is writeably mapped in the address space of the process, it will
> > +be visible in the same file at the same offset even after the system crashes or
> > +is rebooted. This allows users of such mappings to make data modifications
> > +persistent in a more efficient way using appropriate CPU instructions.
> 
> It feels like there's a word missing/unclear wording in the previous
> line, before "using". Without that word, the sentence feels a bit
> ambiguous.
> 
> Should it be:
> 
> persistent in a more efficient way *through the use of* appropriate
> CPU instructions.
> 
> or:
> 
> persistent in a more efficient way *than using* appropriate CPU instructions.
> 
> ?
> 
> Is suspect the first is correct, but need to check.

You're right, the first one is correct.
Jan Kara April 12, 2018, 2:22 p.m. | #3
Hello Michael!

On Thu 12-04-18 15:00:49, Michael Kerrisk (man-pages) wrote:
> Hello Jan,
> 
> I have applied your patch, and tweaked the text a little, and pushed
> the result to the git repo.

Thanks!

> > +.B MAP_SHARED
> > +type will silently ignore this flag.
> > +This flag is supported only for files supporting DAX (direct mapping of persistent
> > +memory). For other files, creating mapping with this flag results in
> > +.B EOPNOTSUPP
> > +error. Shared file mappings with this flag provide the guarantee that while
> > +some memory is writeably mapped in the address space of the process, it will
> > +be visible in the same file at the same offset even after the system crashes or
> > +is rebooted. This allows users of such mappings to make data modifications
> > +persistent in a more efficient way using appropriate CPU instructions.
> 
> It feels like there's a word missing/unclear wording in the previous
> line, before "using". Without that word, the sentence feels a bit
> ambiguous.
> 
> Should it be:
> 
> persistent in a more efficient way *through the use of* appropriate
> CPU instructions.
> 
> or:
> 
> persistent in a more efficient way *than using* appropriate CPU instructions.
> 
> ?
> 
> Is suspect the first is correct, but need to check.

Yes, the first is correct.

								Honza
Michael Kerrisk (man-pages) April 12, 2018, 6:20 p.m. | #4
Jan, Ross.

On 12 April 2018 at 16:22, Jan Kara <jack@suse.cz> wrote:
> Hello Michael!
>
> On Thu 12-04-18 15:00:49, Michael Kerrisk (man-pages) wrote:
>> Hello Jan,
>>
>> I have applied your patch, and tweaked the text a little, and pushed
>> the result to the git repo.
>
> Thanks!
>
>> > +.B MAP_SHARED
>> > +type will silently ignore this flag.
>> > +This flag is supported only for files supporting DAX (direct mapping of persistent
>> > +memory). For other files, creating mapping with this flag results in
>> > +.B EOPNOTSUPP
>> > +error. Shared file mappings with this flag provide the guarantee that while
>> > +some memory is writeably mapped in the address space of the process, it will
>> > +be visible in the same file at the same offset even after the system crashes or
>> > +is rebooted. This allows users of such mappings to make data modifications
>> > +persistent in a more efficient way using appropriate CPU instructions.
>>
>> It feels like there's a word missing/unclear wording in the previous
>> line, before "using". Without that word, the sentence feels a bit
>> ambiguous.
>>
>> Should it be:
>>
>> persistent in a more efficient way *through the use of* appropriate
>> CPU instructions.
>>
>> or:
>>
>> persistent in a more efficient way *than using* appropriate CPU instructions.
>>
>> ?
>>
>> Is suspect the first is correct, but need to check.
>
> Yes, the first is correct.

Thanks for both checking that phrasing. In the end I decided to reword
the sentence a bot more substantially:

              In  conjunction  with  the  use of appropriate CPU
              instructions, this provides users of such mappings
              with a more efficient way of making data modifica‐
              tions persistent.

Thanks,

Michael
Jan Kara April 13, 2018, 11:17 a.m. | #5
On Thu 12-04-18 20:20:12, Michael Kerrisk (man-pages) wrote:
> 
> Thanks for both checking that phrasing. In the end I decided to reword
> the sentence a bot more substantially:
> 
>               In  conjunction  with  the  use of appropriate CPU
>               instructions, this provides users of such mappings
>               with a more efficient way of making data modifica‐
>               tions persistent.

Great, thanks for the improvement!

								Honza

Patch

diff --git a/man2/mmap.2 b/man2/mmap.2
index 47c3148653be..b38ee6809327 100644
--- a/man2/mmap.2
+++ b/man2/mmap.2
@@ -125,6 +125,21 @@  are carried through to the underlying file.
 to the underlying file requires the use of
 .BR msync (2).)
 .TP
+.BR MAP_SHARED_VALIDATE " (since Linux 4.15)"
+The same as
+.B MAP_SHARED
+except that
+.B MAP_SHARED
+mappings ignore unknown flags in
+.IR flags .
+In contrast when creating mapping of
+.B MAP_SHARED_VALIDATE
+mapping type, the kernel verifies all passed flags are known and fails the
+mapping with
+.BR EOPNOTSUPP
+otherwise. This mapping type is also required to be able to use some mapping
+flags.
+.TP
 .B MAP_PRIVATE
 Create a private copy-on-write mapping.
 Updates to the mapping are not visible to other processes
@@ -134,7 +149,10 @@  It is unspecified whether changes made to the file after the
 .BR mmap ()
 call are visible in the mapped region.
 .PP
-Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.
+.B MAP_SHARED
+and
+.B MAP_PRIVATE
+are described in POSIX.1-2001 and POSIX.1-2008.
 .PP
 In addition, zero or more of the following values can be ORed in
 .IR flags :
@@ -352,6 +370,21 @@  option.
 Because of the security implications,
 that option is normally enabled only on embedded devices
 (i.e., devices where one has complete control of the contents of user memory).
+.TP
+.BR MAP_SYNC " (since Linux 4.15)"
+This flags is available only with
+.B MAP_SHARED_VALIDATE
+mapping type. Mappings of
+.B MAP_SHARED
+type will silently ignore this flag.
+This flag is supported only for files supporting DAX (direct mapping of persistent
+memory). For other files, creating mapping with this flag results in
+.B EOPNOTSUPP
+error. Shared file mappings with this flag provide the guarantee that while
+some memory is writeably mapped in the address space of the process, it will
+be visible in the same file at the same offset even after the system crashes or
+is rebooted. This allows users of such mappings to make data modifications
+persistent in a more efficient way using appropriate CPU instructions.
 .PP
 Of the above flags, only
 .B MAP_FIXED