From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by kanga.kvack.org (Postfix) with ESMTP id AB6C16B0007 for ; Wed, 3 Oct 2018 01:36:29 -0400 (EDT) Received: by mail-wm1-f69.google.com with SMTP id y203-v6so3229560wmg.9 for ; Tue, 02 Oct 2018 22:36:29 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id r9-v6sor173621wro.10.2018.10.02.22.36.27 for (Google Transport Security); Tue, 02 Oct 2018 22:36:28 -0700 (PDT) MIME-Version: 1.0 References: <20180921150351.20898-1-yu-cheng.yu@intel.com> <20180921150351.20898-25-yu-cheng.yu@intel.com> <20181003045611.GB22724@asgard.redhat.com> In-Reply-To: <20181003045611.GB22724@asgard.redhat.com> From: Andy Lutomirski Date: Tue, 2 Oct 2018 22:36:15 -0700 Message-ID: Subject: Re: [RFC PATCH v4 24/27] mm/mmap: Create a guard area between VMAs Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Eugene Syromiatnikov Cc: Yu-cheng Yu , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H. J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , "Shanbhogue, Vedvyas" On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov 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