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 B6C48C433E3 for ; Tue, 28 Jul 2020 13:40:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A534206D7 for ; Tue, 28 Jul 2020 13:40:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A534206D7 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 D96346B002C; Tue, 28 Jul 2020 09:40:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D48F18D0003; Tue, 28 Jul 2020 09:40:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5D6B6B0030; Tue, 28 Jul 2020 09:40:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id B03C26B002C for ; Tue, 28 Jul 2020 09:40:30 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6EA6F3620 for ; Tue, 28 Jul 2020 13:40:30 +0000 (UTC) X-FDA: 77087594220.04.shake18_2f0b7dd26f6a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 44E798003F8B for ; Tue, 28 Jul 2020 13:40:30 +0000 (UTC) X-HE-Tag: shake18_2f0b7dd26f6a X-Filterd-Recvd-Size: 3336 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 13:40:29 +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 1k0Pq5-0004Om-5K; Tue, 28 Jul 2020 13:40:17 +0000 Date: Tue, 28 Jul 2020 15:40:15 +0200 From: Christian Brauner To: Steven Sistare Cc: "Eric W. Biederman" , 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, 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, linux-api@vger.kernel.org Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC Message-ID: <20200728134015.tmjy5hy4xden2v5h@wittgenstein> References: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> <87pn8glwd2.fsf@x220.int.ebiederm.org> <28125570-4129-bcba-099b-f90481cfbfe8@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <28125570-4129-bcba-099b-f90481cfbfe8@oracle.com> X-Rspamd-Queue-Id: 44E798003F8B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Mon, Jul 27, 2020 at 02:00:17PM -0400, Steven Sistare wrote: > On 7/27/2020 1:07 PM, ebiederm@xmission.com wrote: > > Anthony Yznaga writes: > > > >> 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. > > > > What is wrong with using a file descriptor to a possibly deleted file > > and re-mmaping it? > > > > There is already MAP_FIXED that allows you to ensure you have the same > > address. > > MAP_FIXED blows away any existing mapping in that range, which is not the > desired behavior. We want to preserve the previously created mapping at There's also MAP_FIXED_NOREPLACE since v4.17 in case that helps. Note that this should really go to linux-api too. I won't argue to resend it since that would mean spamming everyone's inbox with the same thread again but in case you send a revised version, please ensure to Cc linux-api. The glibc folks are listening on there too. Thanks! Christian