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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6A3CC3ABDD for ; Tue, 20 May 2025 11:41:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58CA26B0082; Tue, 20 May 2025 07:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53D806B0083; Tue, 20 May 2025 07:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42C146B0085; Tue, 20 May 2025 07:41:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 247CD6B0082 for ; Tue, 20 May 2025 07:41:21 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AD069120DBE for ; Tue, 20 May 2025 11:41:20 +0000 (UTC) X-FDA: 83463095520.04.29CC3B8 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf18.hostedemail.com (Postfix) with ESMTP id A1FA21C000B for ; Tue, 20 May 2025 11:41:18 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ZTCJx9D6; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=xOipSqIj; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ZTCJx9D6; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=xOipSqIj; spf=pass (imf18.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=pfalcato@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ZTCJx9D6; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=xOipSqIj; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ZTCJx9D6; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=xOipSqIj; spf=pass (imf18.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=pfalcato@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747741278; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0m2C8j6n/4hnJfqAn276hwrxDOhbyeI9i1wZW36wyC8=; b=PXpc9XgKQPY3Qv/VsipE/3LEm9HxW8Jh2E5GMuOMiCo4gR3OIMq1kjpVzWqFqQNvzxC8Gu k2oRwHbOUjSu2aXhuMGu6DeoBHYrORyoipSjL565eghuPOBMgaGw30eWzItTmtuKCE74bW +U5MVs0akqvZ41zvWDxwXAZ9m7iJG3Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747741278; a=rsa-sha256; cv=none; b=sCyM3TD17MN5pBbJEynDK4ZW7HU4b2JXVMoO/yKLDRV5cEkS7FjYC3lfR/NxPx/9jcJEey zSICBNX0iZVdOmz0CpArDWk9Wm3lJ6ZzWAAnlj5Uq/3GfSglUpQNHgN4ZfquXJc5b4FJ5j ztcSCaHU/2od8BIXWOQdOaRueYs2Zdw= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0BDB620687; Tue, 20 May 2025 11:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1747741277; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0m2C8j6n/4hnJfqAn276hwrxDOhbyeI9i1wZW36wyC8=; b=ZTCJx9D6Viz3UpQ90BKvRqWWBnc56CvG4cCpMe1QqrViFPaLNO28D07lE0K4qTMqTXtJiL OsKUdf/r8B2/7UA7e4+M6kW+w92/rRLxWvUyzFmTktimM8wsj7TcI6JMOYZdQLwI7Sejoy SMjWnB1eR7fhtdvV7GYdjljFblBPwyk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1747741277; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0m2C8j6n/4hnJfqAn276hwrxDOhbyeI9i1wZW36wyC8=; b=xOipSqIjQa9bRhV9Sy3AnYuBCGyjt+y2+BQY+DwCXU0OnlDlho/366rdEig0Dq5wHdjEnh +RKFYl7nj3A6JsCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1747741277; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0m2C8j6n/4hnJfqAn276hwrxDOhbyeI9i1wZW36wyC8=; b=ZTCJx9D6Viz3UpQ90BKvRqWWBnc56CvG4cCpMe1QqrViFPaLNO28D07lE0K4qTMqTXtJiL OsKUdf/r8B2/7UA7e4+M6kW+w92/rRLxWvUyzFmTktimM8wsj7TcI6JMOYZdQLwI7Sejoy SMjWnB1eR7fhtdvV7GYdjljFblBPwyk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1747741277; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0m2C8j6n/4hnJfqAn276hwrxDOhbyeI9i1wZW36wyC8=; b=xOipSqIjQa9bRhV9Sy3AnYuBCGyjt+y2+BQY+DwCXU0OnlDlho/366rdEig0Dq5wHdjEnh +RKFYl7nj3A6JsCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C228113A3E; Tue, 20 May 2025 11:41:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id WOx5LlxqLGiSewAAD6G6ig (envelope-from ); Tue, 20 May 2025 11:41:16 +0000 Date: Tue, 20 May 2025 12:41:00 +0100 From: Pedro Falcato To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park , Usama Arif Subject: Re: [RFC PATCH 4/5] mm/madvise: add PMADV_SET_FORK_EXEC_DEFAULT process_madvise() flag Message-ID: References: <617413860ff194dfb1afedb175b2d84a457e449d.1747686021.git.lorenzo.stoakes@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A1FA21C000B X-Stat-Signature: 4ofb81ii6bxnszabzfbd4s8fny7quips X-Rspam-User: X-HE-Tag: 1747741278-186338 X-HE-Meta: U2FsdGVkX18HRqQWrc/rwDkTYUF8iNlS0sjjLkf2FMsWnzIog//m1EhZY77r6fhjhiLYu0YDdbNir8CfonHv4bik+t9ISqen2S0zZkV4uVITJBnRI+FAfdz/ixfM7IAdWt0+EmciQs8csrcTw6/fhl/YfTbF9A6OXSwFbqfKDqzqZ52Ml/YlS9vfSS0M3SFkjYgCVrdpg+uAAVcIgyj5bqVhKDXv+HuK6MJMG/LzrbP8oUWBRPz3PnrjoSfrgHeioQwE+zJ5MinyHvS/1mb2kzRo4Cg4+q9fzCy952qVAxaj9qqVQVpz71t6JmkXcVavEp/qVCcZgwvdssAoPdip4MACaPlFd3iKKBupydES5NkLOhBW946Q+REthWfCmMteAvX/lb/KjjNYv8WPRcqpDj4OG5QKCeLRaX1QQeBQuBb5GBMrajnzqmK/N4ZUD1/qpntCFXOpS/SqitqoXLBhKhFMvWmgSJNu9ZtbOc8Gn4yfXMtMG5h/Na2KwmeLfqDiMUtf47fktfr/8lwiTau7/xkCy+M7nLqQl9bscoah0uAxLf0UORgNw/Hhi2B8njBXNBFxALMowPK0lUUFHZtbZ5rbjVnYNTWbWIYpfnuZucFkZS2q5YIb133E3XHbU+qVxXcSFCTw5Ify/pZ+ShhcBgj3d6OAWLD9D3+1KfeF0XhaCZcpEgh5fPZ34QK4kI8QS++cXO7fDgeL1IKSBe704dtEF82VSYV9xmIxBS5jlWfsJ8A40mK/KVcuypvS90er6njtBR3znjFvpcQIvQCg+aGY7d7JXpbirdnxGyLE9Q+H7S3lCiwORfI2lPXE0DWAQOuBSgcv7GLK1IZm4/WItC0sObcfaT1mt/419Ggv4kdgbjky3Z6Sx3iqVNjtgE0bb6UVKsTOYk9zz7mT/Fc12R2SjRK29EpJckEcGXuheqCMV40KNwZDYd3onOouOMRAeS/vReH/lgN25IEaD/Y gE0guREm miumwvWaSj53bn+t+90e+CEWLDw== 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: List-Subscribe: List-Unsubscribe: On Tue, May 20, 2025 at 11:21:33AM +0100, Lorenzo Stoakes wrote: > On Tue, May 20, 2025 at 09:38:50AM +0100, Pedro Falcato wrote: > > On Mon, May 19, 2025 at 09:52:41PM +0100, Lorenzo Stoakes wrote: > > > It's useful in certain cases to be able to default-enable an madvise() flag > > > for all newly mapped VMAs, and for that to survive fork/exec. > > > > > > The natural place to specify something like this is in an madvise() > > > invocation, and thus providing this functionality as a flag to > > > process_madvise() makes sense. > > > > > > We intentionally limit this only to flags that we know should function > > > correctly without issue, and to be conservative about this, so we initially > > > limit ourselves only to MADV_HUGEPAGE, MADV_NOHUGEPAGE, that is - setting > > > the VM_HUGEPAGE, VM_NOHUGEPAGE VMA flags. > > > > > > We implement this functionality by using the mm_struct->def_flags field. > > > > This seems super specific. How about this: > > > > - PMADV_FUTURE (mirrors MCL_FUTURE). This only applies the flag to future VMAs in the current process. > > - PMADV_INHERIT_FORK. This makes it so the flag is propagated to child processes (does not imply PMADV_FUTURE) > > - PMADV_INHERIT_EXEC. This makes it so the flag is propagated through the execve boundary > > (and this is where we'd filter for 'safe' flags, at least through the secureexec boundary). Does not imply > > FUTURE nor INHERIT_FORK. > > I don't know how we could implement separate current process, fork, exec, fork/exec. > mm->def_flags is propagated this way automatically. > > And again on the security stuff, I think the correct answer is to require sys > admin capability to be able to use this option _at all_. This simplifies > everything. > > To have this kind of thing we'd have to add a whole new mechanism, literally > just for this, and I'd really rather not generate brand new mm_struct flags for > every possible mode (in fact that would probably makes the whole thing > intractible), or add a new field there for this. > > The idea is that we get the advantages of an improved madvise interface, while > also providing the interface Usama wants without having to add some hideous > prctl() whose logic is disconnected from the rest of madvise(), while being, in > effect, a 'default madvise() for new mappings'. > > So while specific to the case, nothing prevents us in future adding more > functionality if we want. > > We could also potentially: > > - add PMADV_SET_DEFAULT (I'm iffy about PMADV_FUTURE... but whichever we go with) > - add PMADV_INHERIT_FORK > - add PMADV_INHERIT_EXEC > > And only support PMADV_SET_DEFAULT | PMADV_INHERIT_FORK | PMADV_INHERIT_EXEC for > now. > > THen we could have the security semantics you specify (require cap sys admin on > PMADV_INHERIT_EXEC) but have that propagate to the only supported case. > > What do you think? > If you don't want to add new fields, this option seems fine. And then if any other usecase pops up, we're ready. > > > > and, while we're at it, rename PMADV_ENTIRE_ADDRESS_SPACE to PMADV_CURRENT, to align it with MCL_CURRENT. > > I'm not sure making the mlock()/madvise() stuff analagous is a good idea, as > they have different semantics. I'd rather keep these flags descriptive. Though > I'm open to alternative naming of course... Semantics are similar I think? And I do think getting shorter names is a good idea, however I won't insist too hard on this. -- Pedro