On Wed, Oct 3, 2018 at 6:32 PM Eugene Syromiatnikov <esyr@xxxxxxxxxx> wrote: > On Wed, Oct 03, 2018 at 09:00:04AM -0700, Yu-cheng Yu wrote: > > On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote: > > > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov <esyr@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote: > > > > > Create a guard area between VMAs, to detect memory corruption. > > > > > > > > Do I understand correctly that with this patch a user space program > > > > no longer be able to place two mappings back to back? If it is so, > > > > it will likely break a lot of things; for example, it's a common ring > > > > buffer implementations technique, to map buffer memory twice back > > > > to back in order to avoid special handling of items wrapping its end. > > > > > > I haven't checked what the patch actually does, but it shouldn't have > > > any affect on MAP_FIXED or the new no-replace MAP_FIXED variant. > > > > > > --Andy > > > > I did some mmap tests with/without MAP_FIXED, and it works as intended. > > In addition to the ring buffer, are there other test cases? > > Right, after some more code reading I figured out that it indeed > shouldn't affect MAP_FIXED, thank you for confirmation. > > I'm not sure, however, whether such a change that provides no ability > to configure or affect it will go well with all the supported > architectures. Is there a concrete reason why you think an architecture might not like this? As far as I can tell, the virtual address space overhead should be insignificant even for 32-bit systems.
