On 12/02/2017 02:19 PM, Matthew Wilcox wrote: > On Sat, Dec 02, 2017 at 07:49:20PM +0100, Jann Horn wrote: >> On Sat, Dec 2, 2017 at 4:05 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: >>> On Fri, Dec 01, 2017 at 06:16:26PM -0800, john.hubbard@xxxxxxxxx wrote: >>>> MAP_FIXED has been widely used for a very long time, yet the man >>>> page still claims that "the use of this option is discouraged". >>> >>> I think we should continue to discourage the use of this option, but >>> I'm going to include some of your text in my replacement paragraph ... >>> >>> -Because requiring a fixed address for a mapping is less portable, >>> -the use of this option is discouraged. >>> +The use of this option is discouraged because it forcibly unmaps any >>> +existing mapping at that address. Programs which use this option need >>> +to be aware that their memory map may change significantly from one run to >>> +the next, depending on library versions, kernel versions and random numbers. >> >> How about adding something explicit about when it's okay to use MAP_FIXED? >> "This option should only be used to displace an existing mapping that is >> controlled by the caller, or part of such a mapping." or something like that? >> >>> +In a threaded process, checking the existing mappings can race against >>> +a new dynamic library being loaded >> >> malloc() and its various callers can also cause mmap() calls, which is probably >> more relevant than library loading. > > That's a bit more expected though. "I called malloc and my address > space changed". Well, yeah. But "I called getpwnam and my address > space changed" is a bit more surprising. Don't you think? > > Maybe that should be up front rather than buried at the end of the sentence. > > "In a multi-threaded process, the address space can change in response to > virtually any library call. This is because almost any library call may be > implemented by using dlopen(3) to load another shared library, which will be > mapped into the process's address space. The PAM libraries are an excellent > example, as well as more obvious examples like brk(2), malloc(3) and even > pthread_create(3)." > > What do you think? > I'm working on some updated wording to capture these points. I'm even slower at writing than I am at coding, so there will be a somewhat-brief pause here... :) thanks, John Hubbard NVIDIA
