Messages in this thread | | | Date | Tue, 15 Aug 2017 12:18:36 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [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
| |