Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]>
Signed-off-by: Jan Kara <[email protected]>
---
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.
.PP
Of the above flags, only
.B MAP_FIXED
--
2.12.3
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 <[email protected]> wrote:
> Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]>
> Signed-off-by: Jan Kara <[email protected]>
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
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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 <[email protected]> wrote:
> > Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]>
> > Signed-off-by: Jan Kara <[email protected]>
>
> 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.
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
--
Jan Kara <jack-IBi9RG/[email protected]>
SUSE Labs, CR
Jan, Ross.
On 12 April 2018 at 16:22, Jan Kara <[email protected]> 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
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
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
--
Jan Kara <[email protected]>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm