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 2B2D0C54EBC for ; Tue, 3 Jan 2023 19:19:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C03BF8E0005; Tue, 3 Jan 2023 14:19:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB38F8E0001; Tue, 3 Jan 2023 14:19:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7B648E0005; Tue, 3 Jan 2023 14:19:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 97C908E0001 for ; Tue, 3 Jan 2023 14:19:57 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 66FEBC0B55 for ; Tue, 3 Jan 2023 19:19:57 +0000 (UTC) X-FDA: 80314452834.25.26533D7 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf09.hostedemail.com (Postfix) with ESMTP id 915FC140018 for ; Tue, 3 Jan 2023 19:19:55 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZqWN8gFU; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.181 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672773595; a=rsa-sha256; cv=none; b=KUtIU0IaAQiKfORfhZbKZr+CbrBAHVrQN+mP8VePbU0Me7InM3csQDLa4BKdL7RrutBBBR eaaa9z08qhIUsByFn/V0yN1hKbFbbohZSIKvv/esewl6C51l45ygs0716NiY5G1pFXeZOy jDJ7gJhSAGpQddHQ/M+LAPN0+Mpugiw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZqWN8gFU; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.181 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672773595; 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=ia/lu5+B5CRXWa8CF3j1BLcFKSU3j2P6kHuicKKTwhM=; b=GtbF0S28kF4bGXuFEp+4MjdkxOgJZd5siO5Q2iLF3coBBdvM6g9/MQ2gcKc0gi/9ewObUe w8fBoSwgasMm1Ex2XjwSJzdD3tK/nEb23VevvrmdhQ41SzBLgPQAHYAPZooxP7j6Tdkpx3 vExBqVF/YtGB5M76b38UobXeA1Ufbd4= Received: by mail-qt1-f181.google.com with SMTP id bp44so22700459qtb.0 for ; Tue, 03 Jan 2023 11:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ia/lu5+B5CRXWa8CF3j1BLcFKSU3j2P6kHuicKKTwhM=; b=ZqWN8gFUfoVI5wnLUXnodqgP701dqeLd5CSt/RsefZ5Qkl5jGfXYOorD034HuIvB5D Ht8gtKf8KI4dn/azdfqIH5esBFN2+qILBHpfWUbepKnmZuifWK677ycRTg3al4Q+XtGT msE8MlX8P1FMZr6Yemo2KVXiq2CyfjHgRvf5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ia/lu5+B5CRXWa8CF3j1BLcFKSU3j2P6kHuicKKTwhM=; b=bQ2GiIe/0p9Xgpcf8cjPOycChmxSSphqJHMZs2xudDMm2KuXMLROsFlZSWYIWH5vCf kkXv7XiIlYAKCW8vmF5de8xizBuuCWrplNmm65zF9Qcdnu0St8zf3wJgCxLXBItjSXxU pE2u28nLVTC021aCIVwtkutayUQf50QAq4eVG3SuR9A112phhmrFALUu5PDZYGom2fES rQbJbeA9I4jbPNOTKq9bgI+94vg/CQus9H15MGsFi69qdJMRB9aIc2QR8ERPy05HmR19 kjC8t46emWrkBuQ/lLfoo1SjFS6YQ4GQmlWZsnPUteJhjXxGQkcDOEFeWjZ4MPCwaQLA t6Pw== X-Gm-Message-State: AFqh2kp7ZktRTPhLxUmu++/bcgKRFVbVsobniG9ZAfHzcyzCFOvp22um DAiC1a0ooaPcGA4Gmf3WdmrR0L1rETLtJm7+ X-Google-Smtp-Source: AMrXdXtGmCpypi857tgDqUl1NURaVz+WnXXGh2Ksa4Xn+u21cyGkX83zkRQru65Xv8RVQjWkSIMe0w== X-Received: by 2002:ac8:45cc:0:b0:3a7:f138:52a3 with SMTP id e12-20020ac845cc000000b003a7f13852a3mr58858379qto.45.1672773594240; Tue, 03 Jan 2023 11:19:54 -0800 (PST) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com. [209.85.160.180]) by smtp.gmail.com with ESMTPSA id fy15-20020a05622a5a0f00b003999d25e772sm19394866qtb.71.2023.01.03.11.19.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Jan 2023 11:19:53 -0800 (PST) Received: by mail-qt1-f180.google.com with SMTP id c7so25310857qtw.8 for ; Tue, 03 Jan 2023 11:19:53 -0800 (PST) X-Received: by 2002:ac8:67da:0:b0:3a5:122:fb79 with SMTP id r26-20020ac867da000000b003a50122fb79mr1194253qtp.452.1672773592726; Tue, 03 Jan 2023 11:19:52 -0800 (PST) MIME-Version: 1.0 References: <20230101162910.710293-1-Jason@zx2c4.com> <20230101162910.710293-3-Jason@zx2c4.com> In-Reply-To: From: Linus Torvalds Date: Tue, 3 Jan 2023 11:19:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings To: Andy Lutomirski Cc: Ingo Molnar , "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 , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 915FC140018 X-Rspamd-Server: rspam01 X-Stat-Signature: mz1k5hy5qpgxo7b5k1i8ryipxn6eq8ks X-HE-Tag: 1672773595-630182 X-HE-Meta: U2FsdGVkX18SdiDhEdevGrJwgjGyWq3nBRDljx4pB8eb9YV/DThxwX0guNm7vbG8well5zEeZB81S2WemS2m4SvHXQ2nK3TNxvTnta68Hwef2xqPT7ZiDxnxTHCd7WDoo+7AuUXMgdeBc5PPws1A4H34igAhd9d9yEWwIlXczhKjrzUaiU/bsr5u8AW9aZTXUBvXMlBqvID/e4QJobdFnMWrBvcmS9e5Syu1OOiK8+3sNzMTvIovJUh2FUxlhWvOytH+ui+Uw8MwnZgiuhQUnDwMMFSSmi4zOil8ctXVJ34wSsJgDN2gk6QWoFOwIyM+l1XjWH/ZkduMm+mOr31Rl1+KzUcMLzRVEFwHjkrT1AhAHTmUGERQK2EBZ1ZMWV4pltJfXeI9gu2MV0t83qBFsxewTzqT1pXu8gRrM9MnwacXUHN12R0tGCA5LNEGz8uhqR72VIJ6YJFM2SMkSe2JmcZKxV0/bRO+P+UA7agrgzry026rSbYQAmQoOffQxNHAAr62d3aetArQJlEMqvjOUHcGOTi1MILWpiHoJy0RXrjbTycrldGqxwRJg/ZTdywaU7Y+hQVheBOYG8+LHj3TR8F1nEebkxFAP+MS7qk9D1LvTads+mVEoVjDu2iCldtnK6KrE0ljKaopWCWo+IG0QwvNRHF7eU6KvT4BNoKZg9ZQVGeS/JmO40Q0dBMII+yWW6R4kXFLC62Z8qK6Qf8feTA0GeiM/Ii+xO70yuamDMRh5mk+azTuBeMfitG0ubBV/QWrG6N/52eylB335FZDtqqwCZHm0J3pDdA75MOQRk9nIkMkvoOggQHCZcHWLLvkZesocllcc1GJMMkC1OUxcSwuEXpTeGeQ/0Bf3eTI7o4KBP1KVKml62XT4jZpErM2O2aRV7nc78nX+qJcURJXBKPD42+qnHQOIQVTeXUvNEl7y4yJFocL1s1Zehu4rEwt7omxXjwd0Z5FdidxorK 2032ekEp u5BEwu79DIltUQIbV8kct0lo9gllbqz8f/ZEDcn5x018j6Qul5IaOQyTNkzDVeIELkvkxv5pNIeAVZ+NYhayPa2sMcsLChDiojbSppHVhoySBcpkQyNcKiBBkLqxQEzY9iR4CKFh8mW08fzUohKH2SJ5nLbzYCfTu66noz1i80ls3gVih5iZREq/p0UKczpPeHtDszfdrrs5kpx3yMIUntaORoCr7xU+x32RYlmvxQJiLNXjzVoq81HDEwfEoP6apDSp0upAkAmrurG/GLm+l1ReaTV1htb95lsnBTfv9+pe8kKj0JstbsdcxeQ2ehVmqt5wkg1+Y6XU2pNh2dKLKagIl3w== 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 Tue, Jan 3, 2023 at 10:36 AM Andy Lutomirski wrote: > > I have a rather different suggestion: make a special mapping. Jason, > you're trying to shoehorn all kinds of bizarre behavior into the core > mm, and none of that seems to me to belong to the core mm. Instead, > have an actual special mapping with callbacks that does the right > thing. No fancy VM flags. I don't disagree, but honestly, my deeper reaction is "this is not worth it". I think the real issue here is that Jason has to prove that this is such a big deal that the VM has to be modified *at*all* for this. Honestly, "getrandom()" performance simply is not important enough to design VM changes for. Do some people care? Debatable. Jason cares, sure. But people have gotten used to doing their own random number implementations if they *really* care, and yes, they've gotten them wrong, or they've not performed as well as they could, but on the whole this is still a really tiny thing, and Jason is trying to micro-optimize something that THE KERNEL SHOULD NOT CARE ABOUT. This should all be in libc. Not in the kernel with special magic vdso support and special buffer allocations. The kernel should give good enough support that libc can do a good job, but the kernel should simply *not* take the approach of "libc will get this wrong, so let's just do all the work for it". Let user space do their own percpu areas if they really care. And most (as in 99.9%) of all user space won't care at all, and is perfectly happy just doing a read() from /dev/urandom or using our existing "getrandom()" without any super-clever vdso support with magic temporary buffer handling. Now, if the magic buffers were something cool that were a generic concept that a lot of *other* cases would also kill for, that's one thing. But this is such a small special case that absolutely *nobody* has asked for, and that nothing else wants. Linus