From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107019 invoked by alias); 28 Feb 2017 17:03:22 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 106846 invoked by uid 89); 28 Feb 2017 17:03:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=late X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f178.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=88MPMNnJ982kTaOJQ64e40Evwq+0hdehGjrigjtUASo=; b=jiUERdtvJgF2BSFuiSZUMISUFymncM7m0AOB/OErQpSt8tHmE/sipyLGBrSkeTj7uW OvWAIzAizLIwpKJ4HKfGsApFHTy7qxtpXJvETetPDeSP5pcbZjbbB8CIE4pmaeSfGMC/ tKECymTx27D54tg5MfAqdC02MK3l4GeslQyHUiHlYP3X2/L+S7x+zrMGMjsodwxlGpiR TCOobom0C3Wzx2yPbPgVOrQY6aWPIHMhspk/reWBoMJejBBybYirHl/THBS5S8fnR28Y dWrMes1QPMi+QlzbucBk4Rs7uMdn7GVT6Oe82XXJdKmBl95z1g05mgulqY2GsqzfbHZO JiBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=88MPMNnJ982kTaOJQ64e40Evwq+0hdehGjrigjtUASo=; b=SLJFjy8ekmY5T+86pVH3PulSPS7osogchWWEbz2W/0ZiQmNUDux1bw23GQR1IMH/Bp LupMfru8uTiwbrmfRp5fXfGQloMeZtDyqQJas8qYr3G+GoYftpUaQRPhsBinVcf0LIbd H9BsedaGfwNv/e1wvbJ3jnfxKBmoLo2WHegvTy5JixUouUWeiHW8OUA9mzxhwk6ybnH1 lylbO4QL6HDGZMogS7RHpaS8AIfVNvnF3rD9lbp4bXfItqjnkCfeBakDJ+f7fic9qMQt VdBdJbopv896sjThAdarntnuObKLi12tZ10D/zifcHInmWUAAnkMr3HlNVHOZggGD4PI IRGA== X-Gm-Message-State: AMke39mZzr/7m0282xNP4dpJLnKeT3gOmlB/Dudf/0hIsSfyQQZTflJOYd9CeLM1J3TfIeyMMVL1YktNwIxYYg== X-Received: by 10.55.138.196 with SMTP id m187mr3722790qkd.124.1488301393632; Tue, 28 Feb 2017 09:03:13 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4982fddd-e7bb-e7f1-d2ee-7aa73066bc8e@redhat.com> References: <4982fddd-e7bb-e7f1-d2ee-7aa73066bc8e@redhat.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: RFC: ABI support for special memory area To: "Carlos O'Donell" Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00004.txt.bz2 On Tue, Feb 28, 2017 at 8:19 AM, Carlos O'Donell wrote: > On 02/23/2017 09:59 PM, H.J. Lu wrote: >>> Why does it run _after_ all shared objects and the executable file are loaded? >> >> Since __gnu_mbind_setup may call any external functions, it can only >> be done after everything is loaded and relocated. > > Who defines this function? Platform vendor with special memory support should provide such function. > Where is it implemented? We are working on libmbind to implement it. > What does a typical implementation look like for MCDRAM use? It uses NUMA, similar to memkind: https://github.com/memkind/memkind to bind pages to a NUMA node. >>> Why not let the dynamic loader choose when it needs to setup the memory? >> >> 1. We want to be able to add support for new type memory by just >> updating the run-time library of __gnu_mbind_setup, instead of >> updating glibc. > > Which library defines it? The default __gnu_mbind_setup is a weak function in ld.so since ld.so can't have undefined function. The real one is in libmbind which overrides the default one in ld.so. > Can two libraries define it? Does the dynamic loader run every DSO's > version of __gnu_mbind_setup? Only one will be used by ld.so. >> 2. Since __gnu_mbind_setup may depend on other libraries, we >> don't want a simple executable requires libfoo and libbar, in addition >> to glibc, nor make libfoo and libbar part of glibc. > > Why can't this be run in a constructor? Is that too late? We can use MCDRAM for dynamically allocated memory with memkind. We are looking for a user-friendly way to use MCDRAM for normal data variables. > This seems like a specialized form of constructor that is guaranteed > to run before all other constructors? Yes. >>>> int >>>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length) >>>> { >>>> return 0; >>>> } >>>> >>>> which can be overridden by a different implementation at link-time. >>> >>> What if you _can't_ bind at ADDR? >> >> It happens on systems without special memory. __gnu_mbind_setup >> returns a positive value and ld.so keeps going. > > Isn't this a violation of what the application binary requested? Even on systems with MCDROM, you may not exceed the limit. The application should still run correctly. > This is a soft-failure that that application doesn't know about. Performance may be lower. But it will run correctly. > Might this become a security issue if the application expected the > specific memory type? __gnu_mbind_setup returns a negative value for fatal error if security is involved and ld.so aborts on fatal error. >>> What if the binding would work if ADD was any value? >>> >> >> GNU_MBIND isn't a LOAD segment, similar to GNU_RELRO: >> >> Program Headers: >> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >> LOAD 0x000000 0x00000000 0x00000000 0x54624 0x54624 R E 0x1000 >> LOAD 0x054e9c 0x00055e9c 0x00055e9c 0x001b0 0x001b8 RW 0x1000 >> DYNAMIC 0x054eac 0x00055eac 0x00055eac 0x00110 0x00110 RW 0x4 >> NOTE 0x000114 0x00000114 0x00000114 0x00044 0x00044 R 0x4 >> GNU_EH_FRAME 0x048eb8 0x00048eb8 0x00048eb8 0x00ff4 0x00ff4 R 0x4 >> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 >> GNU_RELRO 0x054e9c 0x00055e9c 0x00055e9c 0x00164 0x00164 R 0x1 >> >> ADDR contains the start of a memory region within the LOAD segment. > > What are the constraints of GNU_MBIND then? Each GNU_MBIND segment must be aligned at page boundary and within one LOAD segment. > Is it required that it covers only the SHF_GNU_MBIND marked sections which > are part of a PT_LOAD segment? The SHF_ALLOC bit must be set for SHF_GNU_MBIND sections. -- H.J.