Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2829550imm; Wed, 3 Oct 2018 09:46:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV63f3TqPzJCfwcVT//UtpMhRA4cDClEOQSaxTxj1xbKFp3kuhqX/h0yNNWdpHWmbcdJtb020 X-Received: by 2002:a62:4ec9:: with SMTP id c192-v6mr2462804pfb.221.1538585204347; Wed, 03 Oct 2018 09:46:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538585204; cv=none; d=google.com; s=arc-20160816; b=I124/zGN4V8vqxD9+N6SaB/fAuwsXRQtBOFf+x8xN3xwNTG26Atg6kbT9mbLnnALM7 Gbm1j4tuqTQjTqkc3XrOEyIEk+N5IwRst+CtICYP1NA7iq2ESVJLBIdZW4QMTgR1WUyt PSHN5zm6Pw8nGza8EnAw8gDfob313nbK5XyGcWtRl9SnQgW90tHRKvqiwisSYJE2ftpO poG2Y2/CauQzEo1DBQ9tZ3aoK8g6Aki0zuTqmTgzEDtYEJI2dCY3WyYancQRPsEk9vJz iuVAYBr7LWKTMFCVUXYvTACfe0XjNjBeCYA8Ep2EpkFmGiArF3LBlHh+2yhm9YBvU594 8vTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=OkWlY5eNz54eJSwhWeZc8YW60oxE4RnA+1ndE9dLDLY=; b=RUpQPAkNwcPxRThoe+k5XU6i7oV5SOHX/UouZUnA5ZHwtcwwXkorEcM8MXLS4+NgDn rlquztRJ/BsAEopeWkRlQb8F0mgEUfaa8X7Or4mH8hI/yh05M4SFJfnVRn2LZGNHrNAF K2rlJjWjNaGMVyRughKgPcyNMLGv/dqwNNoigJdmU0tNYDgq2jVJHWapb4NW3Xi06IlK CWv37HK9MhTe6fl/wU+KKsTtmCHeV1MzC0GWgDo4aqQH4jmgkElkpacufYzUVDKlV4qv FMohCoOVUOeQIgXDpr1nm5fMRjfu8dt97QIfxhRMXy/LwErNxAGUdqN6mAoduPv/kCCS WjcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h90-v6si1999700plb.64.2018.10.03.09.46.28; Wed, 03 Oct 2018 09:46:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727151AbeJCXfB (ORCPT + 99 others); Wed, 3 Oct 2018 19:35:01 -0400 Received: from mga11.intel.com ([192.55.52.93]:19275 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726842AbeJCXfA (ORCPT ); Wed, 3 Oct 2018 19:35:00 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 09:45:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,336,1534834800"; d="scan'208";a="95767878" Received: from 2b52.sc.intel.com ([143.183.136.147]) by fmsmga001.fm.intel.com with ESMTP; 03 Oct 2018 09:45:38 -0700 Message-ID: <36fa923c4ed6b78517b93475aa2544aa8ba7243c.camel@intel.com> Subject: Re: [RFC PATCH v4 24/27] mm/mmap: Create a guard area between VMAs From: Yu-cheng Yu To: Eugene Syromiatnikov Cc: Andy Lutomirski , 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" Date: Wed, 03 Oct 2018 09:40:58 -0700 In-Reply-To: <20181003163226.GC9449@asgard.redhat.com> References: <20180921150351.20898-1-yu-cheng.yu@intel.com> <20180921150351.20898-25-yu-cheng.yu@intel.com> <20181003045611.GB22724@asgard.redhat.com> <5ddb0ad33298d1858e530fce9c9ea2788b2fac81.camel@intel.com> <20181003163226.GC9449@asgard.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-10-03 at 18:32 +0200, Eugene Syromiatnikov 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 > > > 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. Can we do CONFIG_MMAP_GUARD_GAP?