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 DFDAEC5479D for ; Tue, 3 Jan 2023 19:35:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 651DF8E0003; Tue, 3 Jan 2023 14:35:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 601D68E0001; Tue, 3 Jan 2023 14:35:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CA588E0003; Tue, 3 Jan 2023 14:35:41 -0500 (EST) 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 3AB218E0001 for ; Tue, 3 Jan 2023 14:35:41 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 09A791A0B74 for ; Tue, 3 Jan 2023 19:35:41 +0000 (UTC) X-FDA: 80314492482.15.FDD65FB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 676E540019 for ; Tue, 3 Jan 2023 19:35:39 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=W+5NW3Rq; spf=pass (imf17.hostedemail.com: domain of "SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672774539; 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=AVElIohNFNtKW3ZE1msjI450T/TRBnRTo0iv1QIRm4k=; b=AYDwXeNQEFYp4f0z09aUD0sU1FyO7whS65ImB4j4Kgn3G4EFjZsmnpCMAUMFG5n6wDluym gJEzsSYCvf+VeuINCCOk++FpROoLt8+SmZ6NN0A6xjgfic5eWTvE00uWEckbLbzM0cjhNE J4S1YvsFlVl4OesnFAu4wg43dbqxBFg= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=W+5NW3Rq; spf=pass (imf17.hostedemail.com: domain of "SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672774539; a=rsa-sha256; cv=none; b=mXpPZbvgPoTryShXPLUHRGJmBfBXK0INvxoWi97YA3TDE7niEuDq/sdMfugsNzmcLQD96v i2XzLjOJETic/Pbs43i0L45Citr8B84jkxrnhoTpoO6fOXw2q8Bsn3T7MasSmzWkbO6Fn+ dvo3EcDABDOQNlZr3RgzjMHhTH/CD/Q= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 57ED5614C6; Tue, 3 Jan 2023 19:35:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8B7FC433D2; Tue, 3 Jan 2023 19:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1672774533; h=from:from:reply-to:subject:subject: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=AVElIohNFNtKW3ZE1msjI450T/TRBnRTo0iv1QIRm4k=; b=W+5NW3Rq7Sg7ZuTMgTdUwj03IpK7ihNUOc1Q9h+gBQpWC+QUV6EXFUsODA2AmCv42FNd0e OMb29Km/uY+FlG/OGvBF2xg7gnUad65wYssd7fdkTOERShnrkrQOaaAmje6Ueu8SzufDZk Q3UvdX/gQYNwNIA9tLioErEXt5eNqYg= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id ec6e94ba (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 3 Jan 2023 19:35:32 +0000 (UTC) Date: Tue, 3 Jan 2023 20:35:30 +0100 From: "Jason A. Donenfeld" To: Linus Torvalds Cc: Andy Lutomirski , Ingo Molnar , 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 Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings Message-ID: References: <20230101162910.710293-1-Jason@zx2c4.com> <20230101162910.710293-3-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 676E540019 X-Stat-Signature: 4pyhec4shymgasdq8ikthmm6mwy8z4ex X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672774539-432912 X-HE-Meta: U2FsdGVkX1958RvkWTdkj6byLLd1RzcAmcYAou/38/82Ijq0bDx5g0ylVq8eWa6TroVnrifgnul9130VQ7o052mjXmPnNLJS0bwDPUiIrAMaLJkNcIzBx1ufBBCyJl+xM8BhN3/FuuYEvVhnfj8tN4b1kTWKg8QnUI99u105QbnW0RdSgHKvuiunocXekwi1L4JMKNOgSTqTfqIIiumb9UkMpeW0wdZdjlc/30RBqHEa5Zc2MxMNDN1fGKWiegu0HCEwr+rVXrlnrZvfbPMD19wmJjMOpV3tQeHTt4ex6d5ik4/XWCUG+NHb06d0y3/gAtNk2TyCbcqnF2zzDwE8v2ako0giNXt7CS+n8kFZ+EOcqyENWgNkz3Xp0zzI/4proDCawY1eoVA/cA73uJR/nHL5d3QQzvQOrnRAXNZLqSD4xn+XPIAJJc/lrXR+1IyMI6yIjwO5B4gmThq9ZjKgZfwQ0oXmNYqnnNnWgu2yEbn6j056aksFMZF0W5UkgI0w0phMRx1bD8bcS4du69pHPk+NyakGt06YlmvWjS5BShAKl/hUgZw4r4Ku7rpbfq+7iyeb+5P+XsTuclKdXRgVyP7FQkzb6D8aSXoxnaxZgzQcL4jEHm8PmlKdi+iiovvUgWppGGjJTOMjB20DO56RnyDwkHVtxG9xzLmICdhIC2vZcWdWPNazJkJwwbAlXY6H9DhopImquZ6qIhFW873Kb9gBYWVrTxe7+9Q1Nse19Sh8/3OxQ5hFrrZyUFtBEVt+OWfuSPS8Z062mNf/7VYllhbO9cJ9w46+oPIg+RIKfABo6EhIEKnT4w4tM6GqpaZoj1l+XLUr5Ttf6qDsRvaB0U7jvxKmU+K+jVrkMJ9chA5nG7lGzKN49lSk1hjedKoA0Ec2y/hNlUwvufBAlcyr1FRD/YfTkSY1Ci0kbeaRnsC+6V0eWhjNwShALMewu0RE8WakX0Q3W9+Jm8SzBlh A9SnzF4n rSmBezBUw0KyXyc3hXuyZrekWA6fiQAP8Kkwr0xKVUMwPBU395WsvrzkQxOASOKqW6R6FCXc0hIvVBSdo7dOW1G/zbT0XlmtA9lTCaQ52tAElL132Rb8yBejc7ikCUtpsKNFElfc3T5z/Tb7NrmOYzUVOKwM4U8lnekn+1onqOhU3sqyQg8nlj5H7PgTVZaCHPiCopkaMand1F0wdv1OBj60MYZhGX4AD3ni4G5jK2Mf4s4MDD2e9GhjMhkz4Q7kXbvhlizaMvSqIkvU= 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: Hi Linus, On Tue, Jan 03, 2023 at 11:19:36AM -0800, Linus Torvalds wrote: > 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. I don't think this is about micro-optimization. Rather, userspace RNGs aren't really possible in a safe way at the moment. This patchset aims to make that possible, by providing things that libc will use. The cover letter of this series makes that case. > 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". That's not what this patchset does. libc still needs to handle per-thread semantics itself and slice up buffers and so forth. The vDSO doesn't allocate any memory. I suspect this was Ingo's presumption too, and you extrapolated from that. But that's not what's happening. > 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 Actually, I was thinking VM_DROPPABLE might be a somewhat interesting thing to introduce for database caches and so forth, where dropping things under memory pressure is actually useful. Obviously that's the result of a thought process involving a solution looking for a problem, but I considered this a month or so ago when I first sent this in, and decided that if I was to expose this via a MAP_* flag in mmap(), that should come later, so I didn't here. Anyway, that is all to say it's not like this is the only use for it. But either way, I don't actually have my sights set on it as a general solution -- after all, I am not in the process of authoring a database cache or something -- and if I can make Andy's vm_ops suggestion work, that sounds perfectly fine to me. > thing. But this is such a small special case that absolutely *nobody* > has asked for, and that nothing else wants. Okay so that's where I think you're really quite mistaken. If you recall the original discussion on this, I was initially a bit hesitant to do it and didn't really want to do it that much. And then I looked into it, and talked to a bunch of library and program authors, and saw that there's actually quite a bit of demand for this, and generally an unhealthy ecosystem of bad solutions that have cropped up in lieu of a good one. (I talked about this a bit with tglx at Plumbers, and I had hoped to discuss with you as well, but you weren't available.) Jason