From: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
"Darrick J. Wong"
<darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH v5 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges
Date: Wed, 16 Aug 2017 10:28:21 -0700 [thread overview]
Message-ID: <CAPcyv4i+GbwcqMwKscTmTAuoXnQNfqBtHsxUu-L0+NzNO2f4Lw@mail.gmail.com> (raw)
In-Reply-To: <150286946864.8837.17147962029964281564.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Aug 16, 2017 at 12:44 AM, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> MAP_DIRECT is an mmap(2) flag with the following semantics:
>
> MAP_DIRECT
> When specified with MAP_SHARED a successful fault in this range
> indicates that the kernel is maintaining the block map (user linear
> address to file offset to physical address relationship) in a manner
> that no external agent can observe any inconsistent changes. In other
> words, the block map of the mapping is effectively pinned, or the kernel
> is otherwise able to exchange a new physical extent atomically with
> respect to any hardware / software agent. As implied by this definition
> a successful fault in a MAP_DIRECT range bypasses kernel indirections
> like the page-cache, and all updates are carried directly through to the
> underlying file physical blocks (modulo cpu cache effects).
>
> ETXTBSY may be returned to any third party operation on the file that
> attempts to update the block map (allocate blocks / convert unwritten
> extents / break shared extents). However, whether a filesystem returns
> EXTBSY for a certain state of the block relative to a MAP_DIRECT mapping
> is filesystem and kernel version dependent.
>
> Some filesystems may extend these operation restrictions outside the
> mapped range and return ETXTBSY to any file operations that might mutate
> the block map. MAP_DIRECT faults may fail with a SIGBUS if the
> filesystem needs to write the block map to satisfy the fault. For
> example, if the mapping was established over a hole in a sparse file.
>
> ERRORS
> EACCES A MAP_DIRECT mapping was requested and PROT_WRITE was not set,
> or the requesting process is missing CAP_LINUX_IMMUTABLE.
>
> EINVAL MAP_ANONYMOUS or MAP_PRIVATE was specified with MAP_DIRECT.
>
> EOPNOTSUPP The filesystem explicitly does not support the flag
>
> SIGBUS Attempted to write a MAP_DIRECT mapping at a file offset that
> might require block-map updates.
>
> Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Cc: Jeff Moyer <jmoyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> Cc: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
> Cc: Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> Cc: "Darrick J. Wong" <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Signed-off-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
[..]
> diff --git a/include/linux/mman.h b/include/linux/mman.h
> index 0e1de42c836f..7c9e3d11027f 100644
> --- a/include/linux/mman.h
> +++ b/include/linux/mman.h
> @@ -7,16 +7,6 @@
> #include <linux/atomic.h>
> #include <uapi/linux/mman.h>
>
> -#ifndef MAP_32BIT
> -#define MAP_32BIT 0
> -#endif
> -#ifndef MAP_HUGE_2MB
> -#define MAP_HUGE_2MB 0
> -#endif
> -#ifndef MAP_HUGE_1GB
> -#define MAP_HUGE_1GB 0
> -#endif
This was inadvertent, we need this to build on non-x86 archs, will fix.
next prev parent reply other threads:[~2017-08-16 17:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 7:44 [PATCH v5 0/5] MAP_DIRECT and block-map-atomic files Dan Williams
[not found] ` <150286944610.8837.9513410258028246174.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-08-16 7:44 ` [PATCH v5 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations' Dan Williams
2017-08-16 7:44 ` [PATCH v5 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams
[not found] ` <150286946864.8837.17147962029964281564.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-08-16 11:12 ` Kirill A. Shutemov
2017-08-16 16:29 ` Dan Williams
2017-08-16 16:32 ` Dan Williams
2017-08-16 17:28 ` Dan Williams [this message]
2017-08-16 7:44 ` [PATCH v5 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams
2017-08-16 7:44 ` [PATCH v5 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams
2017-08-16 11:15 ` Kirill A. Shutemov
2017-08-16 16:35 ` Dan Williams
[not found] ` <CAPcyv4gB1JycB_1k6mKe-_OwjZv1a7vPV6Hh393-U_HQ15RWEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-16 16:47 ` Kirill A. Shutemov
[not found] ` <20170816164717.xjbtbdjtwnhvzukg-sVvlyX1904swdBt8bTSxpkEMvNT87kid@public.gmane.org>
2017-08-16 16:52 ` Dan Williams
2017-08-16 7:44 ` [PATCH v5 5/5] fs, fcntl: add F_MAP_DIRECT Dan Williams
2017-08-16 23:42 ` [PATCH v5 0/5] MAP_DIRECT and block-map-atomic files 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=CAPcyv4i+GbwcqMwKscTmTAuoXnQNfqBtHsxUu-L0+NzNO2f4Lw@mail.gmail.com \
--to=dan.j.williams-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=jack-AlSwsSmVLrQ@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-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=linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).