lkml.org 
[lkml]   [2017]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2] mmap.2: MAP_FIXED updated documentation
    From
    Date
    On 12/04/2017 11:08 PM, Michal Hocko wrote:
    > On Mon 04-12-17 18:52:27, John Hubbard wrote:
    >> On 12/04/2017 03:31 AM, Mike Rapoport wrote:
    >>> On Sun, Dec 03, 2017 at 06:14:11PM -0800, john.hubbard@gmail.com wrote:
    >>>> From: John Hubbard <jhubbard@nvidia.com>
    >>>>
    >> [...]
    >>>> +.IP
    >>>> +Given the above limitations, one of the very few ways to use this option
    >>>> +safely is: mmap() a region, without specifying MAP_FIXED. Then, within that
    >>>> +region, call mmap(MAP_FIXED) to suballocate regions. This avoids both the
    >>>> +portability problem (because the first mmap call lets the kernel pick the
    >>>> +address), and the address space corruption problem (because the region being
    >>>> +overwritten is already owned by the calling thread).
    >>>
    >>> Maybe "address space corruption problem caused by implicit calls to mmap"?
    >>> The region allocated with the first mmap is not exactly owned by the
    >>> thread and a multi-thread application can still corrupt its memory if
    >>> different threads use mmap(MAP_FIXED) for overlapping regions.
    >>>
    >>> My 2 cents.
    >>>
    >>
    >> Hi Mike,
    >>
    >> Yes, thanks for picking through this, and I agree that the above is misleading.
    >> It should definitely not use the word "owned" at all. Re-doing the whole
    >> paragraph in order to make it all fit together nicely, I get this:
    >>
    >> "Given the above limitations, one of the very few ways to use this option
    >> safely is: mmap() an enclosing region, without specifying MAP_FIXED.
    >> Then, within that region, call mmap(MAP_FIXED) to suballocate regions
    >> within the enclosing region. This avoids both the portability problem
    >> (because the first mmap call lets the kernel pick the address), and the
    >> address space corruption problem (because implicit calls to mmap will
    >> not affect the already-mapped enclosing region)."
    >>
    >> ...how's that sound to you? I'll post a v3 soon with this.
    >
    > It sounds to me you are trying to tell way to much while actually being
    > a bit misleading. Even sub-range MAP_FIXED is not multi-thread safe.
    >
    > Really the more corner cases you will try to cover the worse the end
    > result will end up. I would just try to be simple here and mention the
    > address space corruption issues you've had earlier and be done with it.
    > Maybe add a note that some architectures might need a special alignement
    > and fail if it is not the case but nothing really specific.
    >

    Sure, I can drop the "how to use this safely" section. It seemed like a good
    idea at the time... :)

    thanks,
    John Hubbard
    NVIDIA

    \
     
     \ /
      Last update: 2017-12-05 08:43    [W:2.243 / U:1.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site