Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2021671ybg; Thu, 30 Jul 2020 08:28:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjgxecjpOzMGDckLTKD7IxXWxww8npyrXSJ1RhXezmTRFCXTPtJFfA+2SJwSKZI1oYX/Q6 X-Received: by 2002:a17:906:8318:: with SMTP id j24mr2998385ejx.409.1596122899708; Thu, 30 Jul 2020 08:28:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596122899; cv=none; d=google.com; s=arc-20160816; b=Zt5a7ZwpbEX+934qGw3DLOGPCWbdLFqU7FqKF5qI5cI8vBiehfaie3NUpUhO4I9fRK 58hCUybhaBHrRtrSjED2VgY63yO4kiphg7OR87eOipdzFmV1n6pPFunJgJ0VbPB+GO4U iIbbEpBooxlWl5rcEi/Xc68Tjc/FAtb9i0G5JxhktC8V5kfZg0WCBLo6/7zGA1EW4k9S ITnEZG+j7iTB8H/+XI91o3sU/zEo8UDlQsvk/ACK8eQQdQLhjp6ApD8GFeRcjsOQDGtv plfce0MhmcATwmPLjqNUel5XvOwTFcLYkKedVHseM6+JLkHyxJRjAq+0ZPn+xK5E7ZUs Q+4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=dK/lbT1AXRwJqX+zU90xc5EZsJ7cmqE+Pj6ZAvr6sL4=; b=lM6Sjmpmqx5eV1mxSYRUfAfqQmGNqpiGCJMTw0tNTszUsyupcUZtlE9DGSeCzyAGr1 +cLJ6d4yg08chmKzaB+gD1+DeGAcplLS6X6IMzhPxa4yK2VbshvazJ1d72OLOH3qC1pw XMmVcDmsqxKFXUBxhnxg2uKExrg05wV5qJICS8oyO/NUSdPpeYseR0hmj8rn0aTRka5Q xhpZ9M87yODtpz6t6Ox6fhXyWdAZaPDs88kiHRFarn7k0KrL0ToyENkrblBGivCz3c8N tF3+LeF/0OpCKCGQfZIlH8BIs7kQXUSbtLaDS2X4rye0av9ggZMhJHASgAYoE8OfYKvz aaFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l25si3660289edv.47.2020.07.30.08.27.56; Thu, 30 Jul 2020 08:28:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729766AbgG3P1N (ORCPT + 99 others); Thu, 30 Jul 2020 11:27:13 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:54880 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbgG3P1N (ORCPT ); Thu, 30 Jul 2020 11:27:13 -0400 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> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!