lkml.org 
[lkml]   [2017]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 3/3] fs, xfs: introduce MAP_DIRECT for creating block-map-sealed file ranges
On Mon, Aug 14, 2017 at 11:12:22PM -0700, Dan Williams wrote:
> MAP_DIRECT is an mmap(2) flag with the following semantics:
>
> MAP_DIRECT
> In addition to this mapping having MAP_SHARED semantics, successful
> faults in this range may assume that the block map (logical-file-offset
> to physical memory address) is pinned for the lifetime of the mapping.
> Successful MAP_DIRECT faults establish mappings that bypass any kernel
> indirections like the page-cache. All updates are carried directly
> through to the underlying file physical blocks (modulo cpu cache
> effects).
>
> ETXTBSY is returned on attempts to change the block map (allocate blocks
> / convert unwritten extents / break shared extents) in the mapped range.
> Some filesystems may extend these same 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 SIGSEGV 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.

We had issues before with user-imposed ETXTBSY. See MAP_DENYWRITE.

Are we sure it won't a source of denial-of-service attacks?

> The kernel ignores attempts to mark a MAP_DIRECT mapping MAP_PRIVATE and
> will silently fall back to MAP_SHARED semantics.

Hm.. Any reason for this strage behaviour? Looks just broken to me.

>
> ERRORS
> EACCES A MAP_DIRECT mapping was requested and PROT_WRITE was not set.
>
> EINVAL MAP_ANONYMOUS was specified with MAP_DIRECT.
>
> EOPNOTSUPP The filesystem explicitly does not support the flag
>
> SIGSEGV Attempted to write a MAP_DIRECT mapping at a file offset that
> might require block-map updates.

I think it should be SIGBUS.

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2017-08-15 11:19    [W:0.857 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site