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
