From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60021 invoked by alias); 7 Jun 2017 18:27:39 -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 59566 invoked by uid 89); 7 Jun 2017 18:27:38 -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.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*F:D*google.com, interest X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f175.google.com Received: from mail-qt0-f175.google.com (HELO mail-qt0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jun 2017 18:27:37 +0000 Received: by mail-qt0-f175.google.com with SMTP id c10so15963985qtd.1 for ; Wed, 07 Jun 2017 11:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XgjKLgwIgc0ltb5w3C8MCbgYXhQh0fWM84GvpYcPN4A=; b=MOnxJgDnXGvJjAnMX7JtwnaNyJuIqVB6isirJBOB/J6yl6KglStSkMzFh2Hf8ZzTPv AirSdZUHl88YPTlxV1ykgq2HkonJYms6U3rmcOu6wdyWBAXKheAvxGLo1PA2cJZ6fP/r tU1GBciGr7iUzikgSTbs15N9dKIVybMSgzttOexfjBXxGmw7Umr9FWXmr0pQfd60KlcN s7xd7dVTMI8OOQP0DiEFG0twqgkN854ey7dqPYyp67JixFw6yY+mGcnnF3URsmw7PTC7 KkbAnPykmGG0KsgLgvEtoM+66aJAtpVhXft4DimdOBasxcEbp8/0eZxSI4bGR3/88dS7 cULA== 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=XgjKLgwIgc0ltb5w3C8MCbgYXhQh0fWM84GvpYcPN4A=; b=tuwDgmPt0lTpoTeVEaE16j520cRaqCVkxGXkBN6Eu3zFd5U79OFvadUIsWr7sgUECm uYKiILgxJ/T8KoA7uN5nmKXTaLQug+sM+QjHp90VyPjnMEJFAsoFJFipo84S3OHgCmqu LCuQ14gil8ExOHTn8yKnbBafFrYQJrIetrxBktETwWalUBBRSZfyAmnFzL16bUs44gnD uaCPyznrGg3HPC7vrVMwsVrqYP5FNqeQjHiKPBnZ3hI12HUqHXf2QYBn/8WKi2h5JHqo Cc0C+2QbbbaPq/CsSUi3ukHPVhVoVKB55LpEJ02FQkE6DvD7MNpU+txhTu1H3B8fAhuN OBHw== X-Gm-Message-State: AODbwcCbIgBUdSWKYWeLK5X5AQaQpP68jdpJeYAcO69TYyPfQWGSLHqW 51ECQHnXp3kCIVXUTKRzw7XvjgE535LJ X-Received: by 10.237.38.193 with SMTP id q59mr37646585qtd.69.1496860060056; Wed, 07 Jun 2017 11:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.55.5 with HTTP; Wed, 7 Jun 2017 11:27:39 -0700 (PDT) In-Reply-To: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> From: "James Y Knight via gnu-gabi" Reply-To: James Y Knight Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: gABI extension proposal: PT_SHMMAP To: "H. Peter Anvin" Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00022.txt.bz2 Why is MAP_SHARED even needed for the linux vdso use-case? All the mappings created for the vdso are read-only mappings, right? And on Linux, MAP_PRIVATE mappings already reflect changes made to the underlying file, so long as the process hasn't written to the page, I think? So, if you're intending to use this to implement the "vvar" mapping, isn't the default MAP_PRIVATE already sufficient? On Wed, May 31, 2017 at 5:23 PM, H. Peter Anvin wrote: > > Hello, > > I would like to propose an extension to the ELF gABI, which is analogous > to PT_LOAD except that it requests that the underlying file be > memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for > PT_LOAD. PT_SHARED or PT_SHLOAD would be other possible names. > > The main motivation for this is to allow the Linux kernel vDSO to > finally become as close to an "ordinary" ELF DSO as is possible. The > vDSO depends on having its kernel-provided data page(s) at a specific > offset from the vDSO code; this is currently done by ad hoc memory > areas, which has a number of problems, especially for mixed-mode programs. > > The idea is to convert the vdso to a proper file in one of the > kernel-provided filesystems (e.g. /proc or /sys); by defining this type, > an ELF parser would be able to create the appropriate mappings without > any ad hoc code. > > This may be usable for other operating systems or perhaps even in > userspace. However, if there is no such interest then it would be > possible for Linux to use one of the PT_*OS constants; however, I > generally believe it is better to try to be as inclusive as possible. > > -hpa