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 37CB4C54E71 for ; Tue, 20 May 2025 22:26:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8604D6B007B; Tue, 20 May 2025 18:26:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8116C6B0082; Tue, 20 May 2025 18:26:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 700366B0083; Tue, 20 May 2025 18:26:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4F4DB6B007B for ; Tue, 20 May 2025 18:26:17 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DB00B1D3CE0 for ; Tue, 20 May 2025 22:26:16 +0000 (UTC) X-FDA: 83464720752.06.1F1140A Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf18.hostedemail.com (Postfix) with ESMTP id CFA521C0005 for ; Tue, 20 May 2025 22:26:14 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=NIkKVhyH; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf18.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.172 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747779975; 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=qTt4YG/1vRUxTQuaxShMs9T/QiIlq/ei1whZCWMU2pI=; b=7SckFp8Nx4bYcr/KxEhOfmX9tKXJpIxsE7wAZHS8af9Ysokx1vj996vEeDt874cNoDpyoM KKpytgeyfn3RrjdZzHFmLyjtAlbj8mfWrDw2QLVe+5c8gW0aa0X0Y+rAD8XfXgcjkUpQK6 u8sAg/AU9T9s+q4g8y3bks7yOh7fbrI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747779975; a=rsa-sha256; cv=none; b=TuuUY0ku7fWMNZt02CFiIwz52Z6TyTb+7xDBtiV2E1K1IoqXg273rqSELrIdY/KUwGaY6C 5D7E3TCh47+AcNNTj425ZsVrAMYHotUejz4mpaUWvHY/t9/JjmRRhseMyjOBPsETswKoYk MYd7mCYmYytQTm1o0Icy2N+YU54gUKU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=NIkKVhyH; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf18.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.172 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-476977848c4so66309991cf.1 for ; Tue, 20 May 2025 15:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1747779974; x=1748384774; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qTt4YG/1vRUxTQuaxShMs9T/QiIlq/ei1whZCWMU2pI=; b=NIkKVhyHL05KS1jHrimqVpwGm02ylOs3p89GjuDKHdRyIw8Xo+j5vFVZcDfdS1Z/rH 04Ch5sT8qhyX/IlDKNeNmZPEr/fcr5C3LD44TOahM3vzIAGel9G+MyPAZSv0eM3jo9AS 2sty5W/ZftrU4lgLtDRa/pojxwK4WRRaUAm0QJBePbqDBwC8risye/lo60Q3heAs4uAd 7M3MVk4EXG+Bue4cdt8Myen5VekGOYaoosJGViWy8F1D1/PxC9Vn6XLEFXlG8es2rJ0V 164HmscBSiJ762RggB+snQOpMDmBBzcDJC31DvqqvrmPeTJOV8wgSvBc7GMkryEHj00W hHhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747779974; x=1748384774; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qTt4YG/1vRUxTQuaxShMs9T/QiIlq/ei1whZCWMU2pI=; b=AvR/NSFtJNWobOF/mNtT12quTbV1228udIipFtGPPabUws4iTN4S/17HaSI+opoU0T f7L1ax2hjaRjvUPXOmgKSwfrVRvvmsY0Njn88rKBCb/3WXN0CG9ZHx+IQavpn4crGx9d Qz69YOI454Ueb3JYxinKURJ6jhq/uhSl51j+LNxarSjLDatMmWa7jSRDl45Bn2S/COEf O1bW3beHv7FMZt09JF+fwwUCnPUvKZv90fUmtjeZPDItak6knJPj7idHZAgAJn4eiXCu BUKnH+8RuqPabJi0gv9jMTKR0Xndtm7369iMj+XVy9NFclnpPnc875vvKfXOii3NuoAQ cxIw== X-Forwarded-Encrypted: i=1; AJvYcCWdEg6BdjbUf75a2w7Br9qsRUG59cHbtsLm1FkDqJ563Gw1iGMNXvlI3qlgtNDxPy2UrRgYV8ZcRA==@kvack.org X-Gm-Message-State: AOJu0YzUlCxLKErVdndc5wEBsdB2AEUCUMOmbxv71h3MNaYvvxUIq4Qe /YrdvaPHreDqEGlErI8T+IetkizuyLK0qIn9sQ6x1s2azP+6KGcbF57UiuOT4khCfaZkJ2uKn3l 3RvCRRmQ= X-Gm-Gg: ASbGncsxAbsPZ1KRbt8U0EKmXru0jtIn5q7mBgVQ7+WXwMYCLXmvBkgsgNcEh1X0JD9 XY9PxfOXjn8WFQUZMYQKrB23maUuvgq1Vwivt8Ks7lN9TRzteULg1zUVLHqxdsBA6xvVLElzTuB oSdWGj2h21UJuvmBjn4K4pZsh1vx5Dw+CoH79cG1ndnh9ji9EtosTwsIzfBXtDzWORyRz5tJcmF vXpeYneVEfkObHP24nnVlcdPeshRYixKBrSUKIffUVeSYH3cx3t23YC0X6uj06pNsOP995GF2Tl waNbS6eIkGmdTskZd1hnwpnxOTI1v9dUbreKLGzEuJox9esNc36GxAcPapBd X-Google-Smtp-Source: AGHT+IHMBmeI7kQYoN9s4JX0ZSBxX+F3xv2rOANEi+wTad8PvFB/MkLVXNhM3peN4djRz8GJun6CxA== X-Received: by 2002:ac8:5cca:0:b0:476:a03b:96ec with SMTP id d75a77b69052e-494ae47d89emr378227251cf.32.1747779973665; Tue, 20 May 2025 15:26:13 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-494ae3f89a9sm76683591cf.20.2025.05.20.15.26.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 15:26:12 -0700 (PDT) Date: Tue, 20 May 2025 18:26:09 -0400 From: Johannes Weiner 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: <20250520222609.GD773385@cmpxchg.org> 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: <617413860ff194dfb1afedb175b2d84a457e449d.1747686021.git.lorenzo.stoakes@oracle.com> X-Stat-Signature: q8t69dz68p3c54xdnaxw1zi576tgtqj5 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CFA521C0005 X-HE-Tag: 1747779974-154296 X-HE-Meta: U2FsdGVkX19pkheSLEp2XPZgFBJNIWGQ+dHSw4KmBtEfpAtmotZ/uMflKabAviGUO2NJxXaIAKYijTrjz2iJq/QaI2XpgYRTJ+svnghEK20vudwDq3F8wCBMkvXn4sVldHzcM5uFjWCdwxDMHMIVegCier9jX0EeUZOHLoKuInjwehAkyv775fEqerDiYTWOsYgIrkewsfTrDfXotHGDopShyiXmqT1d74tezZKeOfM0mIO/xn0Gx8GcSsF0c3GJsQBsxaZv8dzpo3uAhS1g7vwXythopYboEZVrnk4wXctbExvdxMGZnfityFan8N8UYeH1uZ+T1Nw/uRkS1zgwAS9Gq84xR/133mAoH/pB2zetsrJMXrR2o6hYVBZ9PB5jDNUD1FLRNW2IRqLHpq7CpW2r/oKEf956qYbC+G38oH+Dz7SakjoKZ+YP7zS2+0mxJ2uQoDvcG8FTyrOAJJCabze4sOokpJmLAdU9eidO7LGQLMC2KmsEqlT49VTIp3EMtJunJ4QEhToM5sWgh9MddXDLd7UaE4kyj6zJUkoy+Cdbj8hEpqgCbowm05x08V0ebqBGcxI3YMX4qOAiiT/uKMufi+sUmeEHi9Bho77RmH9QoxS21hCXx9ya6ciJLGSynflSoAXXHo3hmgJO1QOOEgAJ3SzsNSABJx+I0U148+Zaa7pYY4OBs+jgVAtu0frEnKjoxRWxormlmo3VODgcmzFy90YLy/krl1dTG56jqozYQh3WFSKotjxxmtgVx8dtZIQSzV2GT0ia48pZ8l0LnDy1NJ/DcbkuOlgVGZaan/INFdf9LtQBR5gixV/PZBYQf9RTPz/JZ/JCf3lqRnnf5m3rfEgVYwA+FmBdqC2T15VOmOHfPaVy7aoBeTABB5NYsC8O4E8yyfXLNcVzFY6FOtiUyJsaVN57lrLSMvjBKdnQdAsulkLm0FjnjTsXJ6WWdLJs7zQDnkwGU3rDMmV IplIOxrN LNewXkD8CByNVfdS0QqNmFA8ZtpIJOrgRbTgJ6EJAQ769RWxL9Kqjv5CO78heCDesJsKUg/XgNIYOzzyjfEROx1IVuwFy4E7gAXD+P9a/lVHyD4gaED6tiWHl7c37saSQhAfDTnPtmsYlj1j9gEPSYwUrgeU+slwiF5R+vFPTBdU6R2+mUSZIzUK81zY0xruSYYp9VfgQ2Eo0WXkYYb8a0oBIDYum2/qdabTty5/I74apzqFXKEkzvUm/OKctajRh0wKQrR8ULD/kUTzjHD8aQHBAjXbRWjWzruaFtmeZ/hWwbnUWLU5DLy2CdlQ1+gRNMU6v4CbNDsurrXPKLjbDZE2T5C3VBX4/p/LvGBAK/YIUbOju9d+4VabKIQvNVDqEA4V4LGWi4s/UnXMndne+prPvqUn427Eqx/P7tb/ShzHmZeSFjKW4JWealYchvxVmbVdU 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 Mon, May 19, 2025 at 09:52:41PM +0100, Lorenzo Stoakes wrote: > 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. Hm, but do we actually expect more to show up? Looking at the current list of advisories, we have the conventional ones: MADV_NORMAL No special treatment. This is the default. MADV_RANDOM Expect page references in random order. (Hence, read ahead may be less useful than normally.) MADV_SEQUENTIAL Expect page references in sequential order. (Hence, pages in the given range can be aggressively read ahead, and may be freed soon after they are accessed.) MADV_WILLNEED Expect access in the near future. (Hence, it might be a good idea to read some pages ahead.) MADV_DONTNEED Do not expect access in the near future. (For the time being, the application is finished with the given range, so the kernel can free resources associated with it.) where only RANDOM and SEQUENTIAL are actual policies. But since those apply to file mappings only, they don't seem to make much sense for a process-wide setting. For Linux-specific advisories we have MADV_REMOVE - action MADV_DONTFORK - policy, but not sure how this could work as a process-wide thing MADV_HWPOISON - action MADV_MERGEABLE - policy, but we have a prctl() for process-wide settings MADV_SOFTOFFLINE - action MADV_HUGEPAGE - policy, but we have a prctl() for process-wide disabling MADV_COLLAPSE - action MADV_DONTDUMP - policy, but there is /proc//coredump_filter for process-wide settings MADV_FREE - action MADV_WIPEONFORK - policy, but similar to DONTFORK, not sure how this would work process-wide MADV_COLD - action MADV_PAGEOUT - action MADV_POPULATE_READ - action MADV_POPULATE_WRITE - action MADV_GUARD_INSTALL - action So the vast majority of advisories are either one-off actions, or they are policies that naturally only make sense for very specific ranges. KSM and THP really seem like the notable exception[1], rather than a rule. And we already *have* prctl() ops to modify per-process policies for these. So I'm reluctant to agree we should drill open and expand madvise() to cover them - especially with the goal or the expectation that THP per-process policies shouldn't matter that much down the line. I will admit, I don't hate prctl() as much as you do. It *is* a fairly broad interface - setting per-process policies. So it's bound to pick odds and ends of various subsystems that don't quite fit elsewhere. Is it the right choice everywhere? Of course not. And can its broadness be abused to avoid real interface design? Absolutely. I don't think that makes it inherently bad, though. As long as we make an honest effort to find the best home for new knobs. But IMO, in this case it is. The inheritance-along-the-process-tree behavior that we want here is an established pattern in prctl(). And *because* that propagation is a security-sensitive pattern (although I don't think the THP policy specifically *is* a security issue), to me it makes more sense to keep this behavior confined to prctl() at least, and not add it to madvise too. [1] Maybe we should have added sys_andrea() to cover those, as well as the SECCOMP prctl()s ;)