lkml.org 
[lkml]   [2018]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
    On Mon, Apr 16, 2018 at 9:57 PM, Michal Hocko <mhocko@kernel.org> wrote:
    > On Mon 16-04-18 21:30:09, Jann Horn wrote:
    >> On Mon, Apr 16, 2018 at 9:18 PM, Michal Hocko <mhocko@kernel.org> wrote:
    > [...]
    >> > Yes, reasonably well written application will not have this problem.
    >> > That, however, requires an external synchronization and that's why
    >> > called it error prone and racy. I guess that was the main motivation for
    >> > that part of the man page.
    >>
    >> What requires external synchronization? I still don't understand at
    >> all what you're talking about.
    >>
    >> The following code:
    >>
    >> void *try_to_alloc_addr(void *hint, size_t len) {
    >> char *x = mmap(hint, len, ...);
    >> if (x == MAP_FAILED) return NULL;
    >> if (x == hint) return x;
    >
    > Any other thread can modify the address space at this moment.

    But not parts of the address space that were returned by this mmap() call.

    > Just
    > consider that another thread would does mmap(x, MAP_FIXED) (or any other
    > address overlapping [x, x+len] range)

    If the other thread does that without previously having created a
    mapping covering the area in question, that would be a bug in the
    other thread. MAP_FIXED on an unmapped address is almost always a bug
    (excluding single-threaded cases with no library code, and even then
    it's quite weird) - for example, any malloc() call could also cause
    libc to start using the memory range you're trying to map with
    MAP_FIXED.

    > becaus it is seemingly safe as x
    > != hint.

    I don't understand this part. Are you talking about a hypothetical
    scenario in which a programmer attempts to segment the virtual memory
    space into areas that are exclusively used by threads without creating
    memory mappings for those areas?

    > This will succeed and ...
    >> munmap(x, len);
    > ... now you are munmaping somebody's else memory range
    >
    >> return NULL;
    >
    > Do code _is_ buggy but it is not obvious at all.
    >
    >> }
    >>
    >> has no need for any form of external synchronization.
    >
    > If the above mmap/munmap section was protected by a lock and _all_ other
    > mmaps (direct or indirect) would use the same lock then you are safe
    > against that.

    \
     
     \ /
      Last update: 2018-04-16 22:18    [W:2.378 / U:0.480 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site