From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B868C433E0 for ; Thu, 30 Jul 2020 15:27:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5A1FA208A9 for ; Thu, 30 Jul 2020 15:27:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A1FA208A9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DF20D6B0002; Thu, 30 Jul 2020 11:27:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7B2E6B0003; Thu, 30 Jul 2020 11:27:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6B316B0005; Thu, 30 Jul 2020 11:27:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id AE9E96B0002 for ; Thu, 30 Jul 2020 11:27:15 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 514B8180AD801 for ; Thu, 30 Jul 2020 15:27:15 +0000 (UTC) X-FDA: 77095120830.22.heat69_5b047b926f7c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 1EDE718038E67 for ; Thu, 30 Jul 2020 15:27:15 +0000 (UTC) X-HE-Tag: heat69_5b047b926f7c X-Filterd-Recvd-Size: 3087 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jul 2020 15:27:14 +0000 (UTC) Received: from ip5f5af08c.dynamic.kabel-deutschland.de ([95.90.240.140] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k1ASY-0005n8-GX; Thu, 30 Jul 2020 15:27:06 +0000 Date: Thu, 30 Jul 2020 17:27:05 +0200 From: Christian Brauner To: Matthew Wilcox Cc: Anthony Yznaga , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, mhocko@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, keescook@chromium.org, gerg@linux-m68k.org, ktkhai@virtuozzo.com, peterz@infradead.org, esyr@redhat.com, jgg@ziepe.ca, christian@kellner.me, areber@redhat.com, cyphar@cyphar.com, steven.sistare@oracle.com Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC Message-ID: <20200730152705.ol42jppnl4xfhl32@wittgenstein> References: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> <20200730152250.GG23808@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200730152250.GG23808@casper.infradead.org> X-Rspamd-Queue-Id: 1EDE718038E67 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 30, 2020 at 04:22:50PM +0100, Matthew Wilcox wrote: > On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote: > > This patchset adds support for preserving an anonymous memory range across > > exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for > > sharing memory in this manner, as opposed to re-attaching to a named shared > > memory segment, is to ensure it is mapped at the same virtual address in > > the new process as it was in the old one. An intended use for this is to > > preserve guest memory for guests using vfio while qemu exec's an updated > > version of itself. By ensuring the memory is preserved at a fixed address, > > vfio mappings and their associated kernel data structures can remain valid. > > In addition, for the qemu use case, qemu instances that back guest RAM with > > anonymous memory can be updated. > > I just realised that something else I'm working on might be a suitable > alternative to this. Apologies for not realising it sooner. > > http://www.wil.cx/~willy/linux/sileby.html Just skimming: make it O_CLOEXEC by default. ;) > > To use this, you'd mshare() the anonymous memory range, essentially > detaching the VMA from the current process's mm_struct and reparenting > it to this new mm_struct, which has an fd referencing it. > > Then you call exec(), and the exec'ed task gets to call mmap() on that > new fd to attach the memory range to its own address space. > > Presto!