Justus Winter, le Sat 13 Sep 2014 02:40:17 +0200, a écrit : > Quoting Samuel Thibault (2014-09-13 01:39:05) > > So it seems we need what is not actually documented, i.e. a vm_map > > with anywhere=1, but which takes into account the suggested address. > > I'm fine with officially supporting that, we just need to fix the > > documentation, > > I'm sorry, I'm lost. What other interpretation of 'anywhere' is > there?
Not taking the address into account at all. > And since you aligned the semantic of vm_maps 'anywhere' with > 'vm_allocate', then it follows that the current interpretation is > either wrong or right for both functions, no? Well, it depends what is documented :) > I just looked at mmap(2). If one specifies a non-NULL address, Linux > will use the address as hint. If it is NULL, and MAP_FIXED is not > given, Linux choses a suitable address. It isn't explicitly stated, > but I'm pretty sure the Linux kernel doesn't consider the zero page a > suitable place. Sure, that's the common Unix semantic, and our mmap implements this from the documented gnumach behavior by trying the suggested address first with anywhere=0, then anywhere=1. > > and fix all places which weren't aware of this behavior (there are > > very few). > > How would I chose a suitable address? E.g. ext2fs/dir.c initializes > the address to 0, but then vm_map_enter would set it to > map->min_offset anyway (or map->min_offset is 0), which is the same as > vm_map_min(map). I've dug a bit more, glibc's _hurd_startup reserves page 0, so no vm_map or vm_allocate call should be allocating at address 0. But with the change, address 0 is already taken by the first mapped binary, ld.so. I guess exec needs to be fixed, and then we can keep the documented behavior. Samuel
