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 1F03EC3DA41 for ; Sun, 7 Jul 2024 18:20:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C91A6B007B; Sun, 7 Jul 2024 14:20:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 178A46B0082; Sun, 7 Jul 2024 14:20:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 067AD6B0083; Sun, 7 Jul 2024 14:20:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DC7FC6B007B for ; Sun, 7 Jul 2024 14:20:10 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 28BEC120EC1 for ; Sun, 7 Jul 2024 18:20:10 +0000 (UTC) X-FDA: 82313770980.29.ED4EB81 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf06.hostedemail.com (Postfix) with ESMTP id 0E1B218000E for ; Sun, 7 Jul 2024 18:20:06 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="c/44pkx0"; dmarc=none; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720376386; a=rsa-sha256; cv=none; b=ZrthlTvCvNYNOdRPNQ9POrZR3257Zljc0kxrKOu38W3G1g5kVqZdI0KkLdgZfG/nDFVc+y ceuGfZfKhb189LYw7i5CCe6vQcK78IJTZ37MjteUreC4uWFDd3geNj0B1gZbUNMkQ0/NEW ySsq7fWI1Erz+LAXHscm+TPatNIgfx4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="c/44pkx0"; dmarc=none; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720376386; 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=5v0Nkh0XR+jIko5z42PL5jDgcJnA00NhojDwz4yKzQ4=; b=48tlv1l+dVUveQ7GtM93jKc1lEQfUf6cVLejJTzGIoCPRb7EUDJKufV6MLXaACyog2OLrg anBRSjauLJGSQnCifgohQI2X/HvRt9flF7ciq5UE20mMdRFwPzoHYluGJPFbRVyOOzQBS8 odV84bNOEM2VyQ70wlap6gpRLYjSN8Y= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-58b447c511eso3976401a12.2 for ; Sun, 07 Jul 2024 11:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1720376405; x=1720981205; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5v0Nkh0XR+jIko5z42PL5jDgcJnA00NhojDwz4yKzQ4=; b=c/44pkx05Omo9zq4ocDfWiFX6kgOGRpw8/2ratsSxSIMhAgQ1HyaLaUC8eu/ZuWUTK Px+KhKJUji/LElonDljDxrioaeG5wf1oFJfODzK6e4bGBFa7kA6KotUiPoCde+EBtk9i XnkSm32tnbYvf00mygIkcDirDNdd/mltBZInM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720376405; x=1720981205; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5v0Nkh0XR+jIko5z42PL5jDgcJnA00NhojDwz4yKzQ4=; b=DIrJnhHOp6vhlprjYbzkQ75VKKVFaUuPz8zoUhjbKNOm6PaJQtgNSTsvCrZqVhnAu0 SGtIbrxB/sK1sXdlYP6H43opTWtRf0PLMXgnxKhwuB7nvPZLtGfw3Jx81C1QvvN7bUq5 hlmL4Q13J6xeUOF/6KJghEpS335n4UwYraD44HOptP43SoeRBoUs9cAd4ZXx6RhPX/Ki uessPz4yw2imqI6gexVTnWhPzYkRILrEjSJlRBiiyXL7fISiABH4NeMcyYg1qajVqsql ODOYh8zYUGIqY9mNnd1P/F4ML0fsp02q7vaIVJ7stz31+f4RXi0GdPgEnTF4nb0JACvP QZsg== X-Forwarded-Encrypted: i=1; AJvYcCXR8hBN4dsSQKtaXQlgH3TqSTGpWQEMkNr2GCfJuEgnofPVcxX3lHnzzcklIdYIh3301i3IeAbQKOTo+NE1kv2KZeg= X-Gm-Message-State: AOJu0Yxrg0B1Dxks/Jmcz7rPATSTzURgrZTPDeHqe6Dg5xLGsn9KQubY Zcz8F01Pj3PgQCjHU/1QDi29dgvdGba3Pi/LyAurxKcQZKxyTaf1/ggwTdsgykDZ8gfknDW/4zG CuQn0dQ== X-Google-Smtp-Source: AGHT+IG44LkzuR9qMcNov8DCj40JqgXV9jVXkOCh3St6kDuzIyS2VnMk8wwd+Yfs5cjU0IwGCa1nHg== X-Received: by 2002:a17:906:8d0:b0:a77:a187:4243 with SMTP id a640c23a62f3a-a77ba72bbc8mr687796766b.72.1720376404906; Sun, 07 Jul 2024 11:20:04 -0700 (PDT) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a72ab065651sm857326166b.126.2024.07.07.11.20.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jul 2024 11:20:03 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a77b550128dso401908966b.0 for ; Sun, 07 Jul 2024 11:20:03 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWfVh9V96nqNoDxfYNLk8E6JrQq7HArPJJmkht4KOrheCeFHw91BcN6O/l70IF6PwK8ayQlpjj8V3qDE0FXzCR6SiY= X-Received: by 2002:a17:906:bc94:b0:a6f:58a6:fed8 with SMTP id a640c23a62f3a-a77ba46f8femr721323266b.28.1720376402830; Sun, 07 Jul 2024 11:20:02 -0700 (PDT) MIME-Version: 1.0 References: <20240707002658.1917440-1-Jason@zx2c4.com> <20240707002658.1917440-2-Jason@zx2c4.com> <1583c837-a4d5-4a8a-9c1d-2c64548cd199@redhat.com> In-Reply-To: <1583c837-a4d5-4a8a-9c1d-2c64548cd199@redhat.com> From: Linus Torvalds Date: Sun, 7 Jul 2024 11:19:46 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings To: David Hildenbrand Cc: "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , "Carlos O'Donell" , Florian Weimer , Arnd Bergmann , Jann Horn , Christian Brauner , David Hildenbrand , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 0E1B218000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7sh4co6mqntwrngbomn51t5w4f7xgsh8 X-HE-Tag: 1720376406-447634 X-HE-Meta: U2FsdGVkX183uoRyIt+ztomvLn7IYTJAf33ztx9TPHw4K7CwevXIMpLKXR7wS3zdIMzwQ5r7bSbezYp7zErSsYAIUXoz3p/hxNRwpmclJjj3gv5zZLs0TM5FrKhol8lZsoQ86kUVhKmWRaVl0fK+sgXpZv3LA45MhgxSWcI4qgrQz1ZBbS+C1olPaPvH6LPpqcDk4CIS+TSNzMXRKP/jV+Y5FMBfbu/lmRc7qf8zcvFk1LmBOt0Dc4QGDB9bd0dWh6FDF/PKQQjaaKkOaJeEeBsi8P4SkXW3djJ+hXz7pZXUH4J3dlYMuoPCJE8sJ/5TK49UoY1QzmTYE1qOO8Q4NL55nOll4t62cr4X0uutAAhS5zgqsQPiBms7EZPHId+eLjPTtnmLeP+NRqy7mxBCUWMlGYK3HxhGCPCNQUhUXTZB3Y9NKwBzX+Qx91Q01O2rSOAlZVoejYziiHYKrGurRvpFaNQGBbChtGIkU7zt5JRXdgXLCD7yQULID8Gn1aj0nKw0/Xd6tHzzG/z1GsF2KfvLFa0QuELJcy6ykPD2tw8E8dXilKHe10B624rVw8nBl6Vur4EkjCbXf4/B3XCUIzz/rA0JGKHdEYyFKDdegUJ6Uhk2cFRtCnXEZwSYlxSkBjjLTgBHFN/0fReNEeUuNamdhV9epAOQjUToGeEOdnmLpNDvkxQsW7SpZzIz+1vww1rjVX+f1bUQ9xOVROH3sYOF3bBwoB6AKCE8+JZPrnJao9YMWyEhdTili2QJlKF+ud4TohOjPGhs7L4MhbkRbGjmChrX+vtxgsPq3hs17s0zvUZpr5SjhMGr2qLMGNKYY4IajdGDfRxGoSIJsDa25/UY5myMvmfzOPtTbPYbMJ8rzT81j55c1DIV6XIY5t8TB6QF3KOis9PoSbL7D6m7/7pF6Mt7HF5IAYRVSLnxl9BOhOeap9wWGUBehBxkAMcCCybFkK9qnCUHQRIa35G 1N4XAZNy 82c+TQDzRJXTlHt7f8kg/ldhQmESEjYdwm/WVPZ5d8vWbaKhkYHsaXrrsEryeLA/bBrl+Y0mqr8wHpW57q5Q4mhfp6YhmXthhjhEo+g56KL0xSgXaQclkqeOvZj3dR+8AOkUmOzME3IoEZ/O+vLQZZbGaZqxi7YVjJdzel+IQyGAGD61v/n3gFpA+53RrKbbCkFREgPj7iJ3KXux15jmr8O16s+1xE4IpxPv93QQAMv5QoSUXTaEn/GuTwRt7hVf2NbKaMEdk8ExDVGY77yNAvq5/VWvtEpYO4ALNGVVacfoDNAx0NlX2r5lCk7T+Diu4QdRdOibZxNHHnKr46Uqdy/JEK5zBtkItdupQzaxwHJieiB4/49N0y+EeKrv1zKc7cXnvI6dplAHjlTRHifSSS+aq6YZIic/v/e8iZKOVj3OHk7BXt0FwzoHAzPLu5vV8da6iwOVVx0Mo+x2sSPBPgVvOtU6jX3yz08igjhQ9kpPpqibYiXIHRZCN5y1JdQ32Bjot4Cgoy8Pa1YmKhbZtvWB5Dgc8qymLQCoMpw/vHuMa8z2f7U/zflgR2mwXTup1Z4igGAmzGux5YqXDtlo2ZhPm3IMHBRtMtKTj 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 Sun, 7 Jul 2024 at 00:42, David Hildenbrand wrote: > > But I don't immediately see why MAP_WIPEONFORK and MAP_DONTDUMP have to > be mmap() flags. I don't think they have to be mmap() flags, but that said, I think it's technically the better alternative than saying "you have to madvise things later". I very much understand the "we don't have a lot of MAP_xyz flags and we don't want to waste them" argument, but at the same time (a) we _do_ have those flags (b) picking a worse interface seems bad (c) we could actually use the PROT_xyz bits, which we have a ton of And yes, (c) is ugly, but is it uglier than "use two system calls to do one thing"? I mean, "flags" and "prot" are just two sides of the same coin in the end, the split is kind of arbitrary, and "prot" only has four bits right now, and one of them is historical and useless, and actually happens to be *exactly* this kind of MAP_xyz bit. (In case it's not clear, I'm talking about PROT_SEM, which is very much a behavioral bit for broken architectures that we've actually never implemented). We also have PROT_GROSDOWN and PROT_GROWSUP , which is basically a "match MAP_GROWSxyz and change the mprotect() limits appropriately" So I actually think we could use the PROT_xyz bits, and anybody who says "those are for PROT_READ and PROT_WRITE is already very very wrong. Again - not pretty, but mappens to match reality. > Interestingly, when looking into something comparable in the past I > stumbled over "vrange" [1], which would have had a slightly different > semantic (signal on reaccess). We literally talked about exactly this with Jason, except unlike you I couldn't find the historical archive (I tried in vain to find something from lore). https://lore.kernel.org/lkml/CAHk-=whRpLyY+U9mkKo8O=2_BXNk=7sjYeObzFr3fGi0KLjLJw@mail.gmail.com/ I do think that a "explicit populate and get a signal on access" is a very valid model, but I think the "zero on access" is a more immediately real model. And we actually have had the "get signal on access" before: that's what VM_DONTCOPY is. And it was the *less* useful model, which is why we added VM_WIPEONCOPY, because that's the semantics people actually wanted. So I think the "signal on thrown out data access" is interesting, but not necessarily the *more* interesting case. And I think if we do want that case, I think having MAP_DROPPABLE have those semantics for MAP_SHARED would be the way to go. IOW, starting off with the "zero on next access after drop" case doesn't make it any harder to then later add a "fault on next access after drop" version. > There needs to be better reasoning why we have to consume three mmap > bits for something that can likely be achieved without any. I think it goes the other way: why are MAP_xyz bits so precious to make this harder to actually use? Together with that whole "maybe use PROT_xyz bits instead" discussion? Linus