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 170A1C3DA41 for ; Sun, 7 Jul 2024 19:23:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57D096B0082; Sun, 7 Jul 2024 15:23:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52CED6B0088; Sun, 7 Jul 2024 15:23:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CDA46B0089; Sun, 7 Jul 2024 15:23:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1D8D76B0082 for ; Sun, 7 Jul 2024 15:23:08 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7028E120D3A for ; Sun, 7 Jul 2024 19:23:07 +0000 (UTC) X-FDA: 82313929614.06.2111DD3 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf25.hostedemail.com (Postfix) with ESMTP id 2302CA0002 for ; Sun, 7 Jul 2024 19:23:04 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=btucNUNB; dmarc=none; spf=pass (imf25.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720380162; a=rsa-sha256; cv=none; b=YKxLpstvQh0U+sXwZPvgyT0x0XWifd8Y2Jedw7Fxb43SUn2G378tmq82qAyamwGOPcW9O8 nbyFvUlRCC/CsUhHUnJlzZ4Y4IpJqQTBV7FvQCoBeHbrxTCFPTAmgMrwAPCarYrEaedY0A spE76aiUt2Gm32hZPjIBFIsdRg0kse8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=btucNUNB; dmarc=none; spf=pass (imf25.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 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=1720380162; 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=r0kqfSkBdmswPIG4hqXsZ+rgeH3ZVa2Soxi8UY2qccM=; b=BLMy9dJHVuQZT9M3iJxBXFWEYa9rE9V+vYk+ujQSKKS19T/lmDP+rj/oV0ZphZ+7hhW1gk JPO97S4FmpM1k2o4/SyX7vQkyUGw3KKnF4eroyQAFxpPn6AuPhhy/JgDuHQ8Olig5MtXNO I3zVPTZtIcyKClVZsPPymW66Buhjy/g= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a77c4309fc8so313885366b.3 for ; Sun, 07 Jul 2024 12:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1720380183; x=1720984983; 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=r0kqfSkBdmswPIG4hqXsZ+rgeH3ZVa2Soxi8UY2qccM=; b=btucNUNBciJEdY1GZd0sRceIuJykZShrztp5mPoBOtJcvlL0rKEwyKaBQn5vEDEQbB EExi07R9MQXGoPwWY7ARdaHxiIKLUDL7dkMF/E50YdmY3bh1F995u84eKi447d5QHkDO 5PpflMhNEqyzookhUyayWuFWxa1Q2zJqzPrJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720380183; x=1720984983; 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=r0kqfSkBdmswPIG4hqXsZ+rgeH3ZVa2Soxi8UY2qccM=; b=qv7fD5M/Ue0QiFR33GBjDDZyUnDrwezewT7fWjhuK8f6TcxnQ+hPTF5oIR4WdEfJLD cD28K4lnNjL4AUCiz/W4z7E+YiMwIWX7UpkUxtLyUMY/enQHpaRiPtEzSVQtdEDRqi9/ GtFTeotJawMlp4Yis4MawLOfJtIgEW9scXIrWuvA5lATDwU6SYK3UYHO7Q/Aub0VWgnQ QTHpaIpFDDTOA6qahPvIjtdv9OmdRmbW4sEzIN62F5tlqrKflUaRTiBvKSsYpYDfs6gH Kp5TkKYRUwZpEsiLdCkxqNInAdbSZi8JLm/Vy2tqRp0AL39yJG/sXiOYoZSo/fDOwXaW VKEg== X-Forwarded-Encrypted: i=1; AJvYcCXNlM2jOBwfM572nW5B7+b42MwSdmtiyOgp8ZTYaTqeQnXAu7Qrl3GdR5Ig2SolHajY8VNiT2j8PA/d+dFnijI31Ck= X-Gm-Message-State: AOJu0YzaVwBCXOElzrnFegwCskdR6gx43TqjXWv9gRtyGy7a1TeZ25fr YhxgtWgtTNGaWqSkiQ3t33RPSACngVsn7QyIQe4g9TP2ZDdLMEdPD4Bb6F7Sr63exhhuRaYlQzV 7XGvNQw== X-Google-Smtp-Source: AGHT+IFospkYgtGZ7EdFFXFpmiI1wo5Pp2pOJJ0JQdAX2jlp8JDxHnCUf0AKHf6pp4K9TRN9f9WVvg== X-Received: by 2002:a17:907:7f1f:b0:a6e:fb9b:6769 with SMTP id a640c23a62f3a-a77ba72c462mr847131166b.75.1720380183253; Sun, 07 Jul 2024 12:23:03 -0700 (PDT) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com. [209.85.218.42]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a77db2b70a3sm202246666b.81.2024.07.07.12.23.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jul 2024 12:23:01 -0700 (PDT) Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a77c9c5d68bso260389066b.2 for ; Sun, 07 Jul 2024 12:23:01 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXTQcKbKBldpcxsWwqQxVnBNlKOSXvS+CDb5kCC5SbDznZdlAXCC7zvdauMJG80L6fdTH2mHm34DiuxGlMK+VHDawo= X-Received: by 2002:a17:906:7708:b0:a75:3c31:4f58 with SMTP id a640c23a62f3a-a77ba46fa2bmr620405066b.32.1720380181227; Sun, 07 Jul 2024 12:23:01 -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: From: Linus Torvalds Date: Sun, 7 Jul 2024 12:22:44 -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-Server: rspam12 X-Rspamd-Queue-Id: 2302CA0002 X-Stat-Signature: frtzhnkxmi8mrxadus54e65e96fmmeir X-Rspam-User: X-HE-Tag: 1720380184-552715 X-HE-Meta: U2FsdGVkX19S+xtTdmCwllYrBI4462Iwr8YKZOruseuP86t76atcIspyxf2b6AF+DSgjdqEbGNlwdfp3Nz6wMaYEzM5sWDK8QYOzF4IwMJx88M8OHDi660SmF8epxN40mSjLfKEt6FP5zfpdbk3YMdYGKGPzmatMUrr3xQiC7Q+CDJMlV+zrZUMyjBygWM/S3gvBNhX/33EBCSZ9mTDO76e8sDvN8mhFCV5pbYWZDTUS6O7EQNCAV5CeUg+/3oe4c1HAY7+yYUycXxgnHR9+kwZhFfkB9rc3Lm2WF6ar4iOLhqQyQzm7cuZlzG1tPTrAPZV61W4VXF6Ox3q501/o+VnONSk3KBQTqIyqZ4NUmrRoXXawlhJw9bnxSbFEt5PnslEgUJf6a0XXui8sdsDjMjisSo9BB1hQmb5lNvHVJ8F3D8NUreQ7M0onymmby4xKRmDObt4Y7UXMp05Rn2qJH/ELFYXnaLSFTU3zxfUJ8ysPUxc/tSl7TM4EQDeCz9s6dOysxB9r3F9Kl1oJs3lvqpucsAqsj3Ex4XRbDnicvpHERU57vWLZbbx0v/5xfKNM7vJzafNblN9BcPW4TAwW4RNzzpmUJd2LsKH2RPOG/Akzo1+pRhE2P8FAm7dvyw0KqWg0BOqy/VqpybGkNlS1xWq9WxHebNTc5qoYP2oPDJWQjGfOK1USdwZZPUe+zCuE1ebY4xm4LvInQ4oKPQus0Gp/aKUEfdkg/jghQX06wEX2zdJxSDGOYGqHn1PHANtZDOJBWjfBWzM/0w5Qnl5WCrSr0tu2Z8qctHXm/lWbsO5CBd2buGU/0q0HT+HVi5twZQL7hU8DZ92Iu0YBaHyq9xg2I7ccs2VAjRoaCc7gkQLRzBp0SbviM2C8RrKzvfULrkKakJT8jh6ZglfGisq9lBak3XnydYRhm5pNkhWygN420VRMGipqlQKSpAAa+0LFuPVJmuNLe7Qn0STmoLp uE++yaoD +PIzONrYYXHD8cAw9VMmRcqBMHhMYfaGJuf7x2pf8qN+Xr9eFk3Ws+zcM/t90U7L3VdUPxS+rrCz7+UEQ+h3XBxDB7Jgjmxhd24/ukPAdf/DctI54mCy4wKHHYDB2YAQBusM9kaw98Tl542pHCYJN+SCjpjIkB9UPTQkm+IQ/rcq9kBfU1gtgXHFczJLJbx0oedAu7y+CfAEliUYlKrkpy2uyONPrgJNMvUDA90ZNdECybgmEzmg0ln7CWdmyf96+lF2rTbiT6J7EeuvRYKRmqWZm/kIfHq80bziyE+f0tTjYV0H/fh4DG+pg60G5rKDHC3kReU6UHekFDUasIf8mAC7zSQIZV07kJcEHWoZZiU1Q0BzfB7vi/mtz5Arj3x5RJyrMpSUE4We9/80bcQtK/f4XjErGmgAJm80glvXn6E8z226KRKyO4Wa1dPfPR4JWrgXYnskWWinlMidmExwONnBniwhfw9Yoool5SNGIU54cxY2PjZqFJsBIEFeLnVvX2LicHZz8uLJuIS27pLFVjC0HVmVseTv9GLUeCOMXtKr+Qn1onaA2Ikhdfg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, 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 11:52, David Hildenbrand wrote: > > I recall that introducing things like MAP_SHARED_VALIDATE received a lot > of pushback in the past. But that was before my MM days, and I only had > people tell me stories about it. I think MAP_SHARED_VALIDATE was mostly about worrying about the API impact. And I think it worked out so well that this is probably the first time it has been brought up ever since ;) That said, the *reason* for MAP_SHARED_VALIDATE is actually very valid: we have historically just ignored any random flags in the mmap() interfaces, and with shared mappings, that can be dangerous. IOW, the real issue wasn't MAP_SHARED_VALIDATE itself, but introducing *other* flags that affected maps that old kernels would ignore, and then the worry was "now old kernels and new kernels work very differently for this binary". That's technically obviously true of any MAP_DROPPABLE thing too - old kernels would happily just ignore it. I suspect that's more of a feature than a mis-feature, but.. > My understanding so far was that we should have madvise() ways to toggle > stuff and add mmap bits if not avoidable; at least that's what I learned > from the community. It doesn't sound like a bad model in general. I'm not entirely sure it makes sense for something like "droppable", since that is a fairly fundamental behavioral thing. Does it make sense to make something undroppable when it can drop pages concurrently with that operation? I mean, you can't switch MAP_SHARED around either. The other bits already _do_ have madvise() things, and Jason added a way to just do it all in one go. > Good to hear that this is changing. (or it's just been an urban myth) I don't know if that's an urban myth. Some people are a *lot* more risk-averse than I personally am. I want things to make sense, but I also consider "this is fixable if it causes issues" to be a valid argument. So for example, who knows *what* garbage people pass off to mmap() as an argument. That worry was why MAP_SHARED_VALIDATE happened. But at the same time, does it make sense to complicate things because of some theoretical worry? Giving random bits to mmap() sounds unlikely to be a real issue to me, but maybe I'm being naive. I do generally think that user mode programs can pretty much be expected to do random things, but how do you even *create* a mmap MAP_xyz flags field that has random high bits set? > > We also have PROT_GROSDOWN and PROT_GROWSUP , which is basically a > > "match MAP_GROWSxyz and change the mprotect() limits appropriately" > > It's the first time I hear about these two mprotect() options, thanks > for mentioning that :) Don't thank me. They actually do make sense in a "what if I want to mprotect() the stack, but I don't know what the stack range is since it's dynamic" kind of sense, so I certainly don't hate them. So they are not bad bits, but at the same time they are examples of how there is a fuzzy line between MAP_xyz and PROT_xyz. And sometimes the line is literally just "mprotect() only gets one of them, but we want to pass in the other one, so we duplicate them as a very very special case". Linus