Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751914AbaF0Rev (ORCPT ); Fri, 27 Jun 2014 13:34:51 -0400 Received: from mga09.intel.com ([134.134.136.24]:43369 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751675AbaF0Reu (ORCPT ); Fri, 27 Jun 2014 13:34:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,561,1400050800"; d="scan'208";a="564598054" Message-ID: <53ADAB39.6030403@intel.com> Date: Fri, 27 Jun 2014 10:34:49 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andy Lutomirski CC: "Ren, Qiaowei" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , X86 ML , "linux-kernel@vger.kernel.org" , Linux MM Subject: Re: [PATCH v6 02/10] x86, mpx: add MPX specific mmap interface References: <1403084656-27284-1-git-send-email-qiaowei.ren@intel.com> <1403084656-27284-3-git-send-email-qiaowei.ren@intel.com> <53A884B2.5070702@mit.edu> <53A88806.1060908@intel.com> <53A88DE4.8050107@intel.com> <9E0BE1322F2F2246BD820DA9FC397ADE016AF41C@shsmsx102.ccr.corp.intel.com> <9E0BE1322F2F2246BD820DA9FC397ADE016B26AB@shsmsx102.ccr.corp.intel.com> <53AB42E1.4090102@intel.com> <53ACA5B3.3010702@intel.com> <53ACB8A7.9050002@intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/26/2014 05:26 PM, Andy Lutomirski wrote: > On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen wrote: >> On 06/26/2014 04:15 PM, Andy Lutomirski wrote: >>> Also, egads: what happens when a bound table entry is associated with >>> a MAP_SHARED page? >> >> Bounds table entries are for pointers. Do we keep pointers inside of >> MAP_SHARED-mapped things? :) > > Sure, if it's MAP_SHARED | MAP_ANONYMOUS. For example: > > struct thing { > struct thing *next; > }; > > struct thing *storage = mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...); > storage[0].next = &storage[1]; > fork(); > > I'm not suggesting that this needs to *work* in the first incarnation of this :) I'm not sure I'm seeing the issue. I'm claiming that we need COW behavior for the bounds tables, at least by default. If userspace knows enough about the ways that it is using the tables and knows how to share them, let it go to town. The kernel will permit this kind of usage model, but we simply won't be helping with the management of the tables when userspace creates them. You've demonstrated a case where userspace might theoretically might want to share bounds tables (although I think it's pretty dangerous). It's equally theoretically possible that userspace might *not* want to share the tables for instance if one process narrowed the bounds and the other did not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/