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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 2C47DC433DF for ; Fri, 31 Jul 2020 17:23:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BACD122B3F for ; Fri, 31 Jul 2020 17:23:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="VfUjSEfR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BACD122B3F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 20D046B007D; Fri, 31 Jul 2020 13:23:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BDD48D000B; Fri, 31 Jul 2020 13:23:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D4B46B0080; Fri, 31 Jul 2020 13:23:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id EC61D6B007D for ; Fri, 31 Jul 2020 13:23:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 48FD1181AC9CB for ; Fri, 31 Jul 2020 17:23:51 +0000 (UTC) X-FDA: 77099043462.03.flag89_390e1a326f85 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 254F028A4E9 for ; Fri, 31 Jul 2020 17:23:51 +0000 (UTC) X-HE-Tag: flag89_390e1a326f85 X-Filterd-Recvd-Size: 4368 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jul 2020 17:23:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1mijjRYuRlV1nsas7+RkkJeUm22srBJgqC/kjl8CxTo=; b=VfUjSEfRmnrJ+EhnkKqaubP8LY bPDymb+ADlyxt4KSFmNG0Kdi9f0XdEd3AGurw1Iq1LfD3qNEFLgZg5KXh3fjBauS+N3hpvaoF2KCz 6qDSKlY6nElZV7JEGX5vEWwcXkW7KdWomh3ez+xbuveQumtBN9ETF65jZxsfubRxRYSE6KC2QY9Jz l4SdO5PEVzXiyZge4/yp5ddWWP8TqXfSoXy2ce0B7OsiSsK4zXCJSVCtfK8jPJQtcpzJ2+Ep3YeXh JmGNgfodGHSCuxWnen/BJOFvJKpMd4185WrTmsN7H330wpeVTaZ/nCYJRedW3ux9Tqh3wXb6H5Vd9 T3UAQkyA==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1Ykr-0008T6-G9; Fri, 31 Jul 2020 17:23:37 +0000 Date: Fri, 31 Jul 2020 18:23:37 +0100 From: Matthew Wilcox 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, christian.brauner@ubuntu.com, peterz@infradead.org, esyr@redhat.com, jgg@ziepe.ca, christian@kellner.me, areber@redhat.com, cyphar@cyphar.com Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC Message-ID: <20200731172337.GQ23808@casper.infradead.org> References: <20200730152250.GG23808@casper.infradead.org> <20200730171251.GI23808@casper.infradead.org> <63a7404c-e4f6-a82e-257b-217585b0277f@oracle.com> <20200730174956.GK23808@casper.infradead.org> <87y2n03brx.fsf@x220.int.ebiederm.org> <689d6348-6029-5396-8de7-a26bc3c017e5@oracle.com> <20200731152736.GP23808@casper.infradead.org> <9ba26063-0098-e796-9431-8c1d0c076ffc@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ba26063-0098-e796-9431-8c1d0c076ffc@oracle.com> X-Rspamd-Queue-Id: 254F028A4E9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote: > On 7/31/2020 11:27 AM, Matthew Wilcox wrote: > > On Fri, Jul 31, 2020 at 10:57:44AM -0400, Steven Sistare wrote: > >> Matthews sileby/mshare proposal has the same issue. If a process opts-in > >> and mmap's an address in the shared region, then content becomes mapped at > >> a VA that was known to the pre-fork or pre-exec process. Trust must still > >> be established. > > > > It's up to the recipient whether they try to map it at the same address > > or at a fresh address. The intended use case is a "semi-shared" address > > space between two processes (ie partway between a threaded, fully-shared > > address space and a forked un-shared address space), in which case > > there's a certain amount of trust and cooperation between the processes. > > Understood, but if the recipient does map at any of the same, which is the whole > point because you want to share the page table. The trust relationship is no > different than for the live update case. You don't have to map at the same address to share the page tables. For example, on x86 if you share an 8GB region, that must be aligned at 1GB in both the donor and the recipient, but they need not be mapped at the same address. > > It's a net increase of 200 lines of kernel code. If 4 lines of userspace > > code removes 200 lines of kernel code, I think I know which I prefer ... > > It will be *far* more than 4 lines. > Much of the 200 lines is mostly for the elf opt in, and much of the elf code is from > anthony reviving an earlier patch that use MAP_FIXED_NOREPLACE during segment setup. It doesn't really matter how much of it is for the opt-in and how much is for the exec path itself. The MAP_FIXED_NOREPLACE patch is only net +16 lines, so that's not the problem.