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 E4BDBC54E76 for ; Fri, 6 Jan 2023 02:42:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79AEE8E0002; Thu, 5 Jan 2023 21:42:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74AF78E0001; Thu, 5 Jan 2023 21:42:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C7308E0002; Thu, 5 Jan 2023 21:42:42 -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 495EA8E0001 for ; Thu, 5 Jan 2023 21:42:42 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 03E92A5BC9 for ; Fri, 6 Jan 2023 02:42:41 +0000 (UTC) X-FDA: 80322826164.14.5AEB80E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf15.hostedemail.com (Postfix) with ESMTP id 36044A000C for ; Fri, 6 Jan 2023 02:42:38 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=ny+dCxXQ; spf=pass (imf15.hostedemail.com: domain of "SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=h6oe=5D=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=1672972959; 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=g1mMlBEGSH2yJeXHfEJcLsexhlCzf0SSwDSRSbPe6+4=; b=zxASWV1mjC1ii/zTO3Aocy3UVufG/tC2D9Dp7ptgLcJeu2TP5pH3PPWFFgMjFr9XesZYe4 5qmo7nob4jTTzLqlx0WxkRPFqr40lspNpwiaJ9nPHVUpqYMtzb2arJRkC7D42/SQ+pgVcy /Ovck9x4pCwWnZhZQL7xRGSwMyDeiRE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=ny+dCxXQ; spf=pass (imf15.hostedemail.com: domain of "SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672972959; a=rsa-sha256; cv=none; b=dvVXZ2vO2usw0eU8cufvO0CL/q5R9F9xnUYEtipO5MMffi1MV/Wl5mnQhzg05Ff8R8yjUd P++SqShxgkoeN7gdvbu/ZBpUoHR/ZOn6Z9WGd2xT8Lu9ayWzqdUayuE93b6I8E4fQA3FVC 174mwgHlhl5/wJsa0JqIcMx+l6dCOlg= 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 ams.source.kernel.org (Postfix) with ESMTPS id 78C3AB81C1B; Fri, 6 Jan 2023 02:42:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48C6DC433D2; Fri, 6 Jan 2023 02:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1672972951; 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=g1mMlBEGSH2yJeXHfEJcLsexhlCzf0SSwDSRSbPe6+4=; b=ny+dCxXQ/0DuBUk+XJHzeaUeqT3EVGKAl2Rr/lYLEYrmHIJQ+MtDOg153v2IZImUWbtoig lBdmtGmPSXabTgE1Eq9qNkpvwrBAw3PPVOtNlibVP70ZIK94iVKC6HLt5FtPyDCWJ1UkN5 W85ewNz9OiZziXXdzYUzyDzqup9d0c4= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 71928115 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 6 Jan 2023 02:42:31 +0000 (UTC) Date: Fri, 6 Jan 2023 03:42:28 +0100 From: "Jason A. Donenfeld" To: Linus Torvalds Cc: Yann Droneaud , 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: <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 36044A000C X-Stat-Signature: scjaeymtyuszr7pzue65ucppts91yb3r X-Rspam-User: X-HE-Tag: 1672972958-176923 X-HE-Meta: U2FsdGVkX1/fRlkQbkW+Sc0WQutUuCYCEBjNqFhYgPU3U5QQxolXpolUy7CRgamz3DQFkvLdJccq+0hIMylz8jM4eUUIfcuJwuUlY3O53bm8VpuPR8/CSS5LvIFGXgPoR78jq78MVIeDpgRE2GUry6Udpagp4BIa5PYxIi04mkctOBr/MwaLzXesk3GUjs3DMxE6fKf6/h3E4Etk0QNfcvoE96s+Q8mk5q2LroGRTFA6keDS4C+8HeADLimBo/zxh2IMLp+HEMheN9oNVxSololoTdHilvia7dary9vNnmmcXR9v11mgtlvwL6fwBZTCUz4x7jro9VBZhVvZqmcrmLwDPnVAQwzHA8MtZST2oH7oZ+aqb71ZASQVQ2tOrAZMCoBCwPybcybfNF9VABawleYlSbK8CkQFCfiZWFJCtajhfxqyJHerQHIoQ7iBWhoiOspn71+VIw1M9oa642HKousUOKwxSjv2eDiFF8iMAa8wq4EsbtPT8hFKzMFj9GitJQ6CJYOl5wGrBBQYbNXQ9vHAup1eFy0zQeLJA8ToPTYIVWJ6FRe8X3tvJ6ubMAxgwcpPw2JO8o+RLbpItUSF4e8yRBB3IfTbX7Dh28EvkxT2A/e+8SSqTbhadWBhf08UskSCqWAMN9X3Pce27IiyMaHE8YXFAX3WybgJ1vHfu7b7fth4/mv3sBOReKeVLz2OQS1Zw9Kxo+NaPE6cSUtri1lTM3DfrXHDXXQPBlwlzwL0jlkF8+3YC7U/UxpktfcRUfSYA4CdTnKC/Ymz105XoDTm82Ebvr3wY+vTliReT8iTXVUgtAjf0SurPxH9AI43AoqoDUJUotk3Qs0BZvet0a/mqXVbvzkLs5kZYd3gjVnhKtL1571KH/M3s7VMpUTcfUA2x4AOaKKht6cSOpJnf976iEeRGhDlqGqT+T29M3o1qxuUDi3jliFJSWPN2mlk037Ba69AMjbHYj5v1yx cNnnMfMg UzzcZMv8bsall5CkCRc81O7wjBl5QnhTcRUAW2ApuF9qlXhtyCbwngmc5UXWuKMpXbDIouVQzuagKhlfzyWTITWSLOwi0++ZsOA+HB06BbDF4fk7qPX4u/a9up1X7S+I1Bqxz19Je34Jn6T9s4TUp5VFToDAN6uYu41A/+zo7/9gmW7rlnuaAZj8+nPqR/MrLAvNejDahqErZRwP1DwJQFL0KhvgMM+2LAmPWirhTh0tI0VgYpxbj4Eilwd3TPJGfbqIKtf6RlCHBwxQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001794, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 05, 2023 at 06:08:28PM -0800, Linus Torvalds wrote: > (although honestly, we should solve the 32-bit > problem first - ignoring it isn't fine for anything that is supposed > to be widely useful). Yea, the 64-bit aspect of that patch is pretty gnarly. I would hope that if converting the field to be 64-bit everywhere, the compiler would still generate good code for most cases, when testing against common-case constant bit masks that are half unset, but I didn't look into it. Indeed if this is to become something real, that'd be a worthwhile pre-requisite project. > And I think VM_DROPPABLE matches (a), and would be fine if it had some > other non-made-up use (although honestly, we should solve the 32-bit > problem first - ignoring it isn't fine for anything that is supposed > to be widely useful). > > We *have* talked about features kind of like it before, for people > doing basically caches in user space that they can re-create on demand > and are ok with just going away under memory pressure. > > But those people almost invariably want dropped pages to cause a > SIGSEGV or SIGBUS, not to come back as zeroes. Yea it seems intuitively like that would be a useful thing. Rather than trying to heuristically monitor memory pressure from inside uncoordinated userspace apps, just have the kernel nuke pages when it makes sense to do. The thing is -- and this is what I was trying to express to Yann -- while I have some theoretical notion of how it /might/ be useful, that's mainly just a guess from me. But one could run around discussing the idea with actual potential users of it, and see if anyone's eyes light up. And then once, for example, the Chrome renderer team is clamoring for it, then hey, there'd be a good use that wouldn't be bound up with security models not everybody cares about. > So you were insulting when you said kernel people don't care about > security issues. And I'm just telling you that's not true, but it Maybe you read that without looking at the end of the sentence which read: ", assuming that the concerns are unreal or niche or paranoid or whatever." Because the email you sent in response pretty much described the concerns as either unreal or niche. So I didn't mean to be insulting. I actually think we agree with each other on the nature of your position. > *is* 100% true that kernel people are often really fed up with > security people who have their blinders on, focus on some small thing, > and think nothing else ever matters. > > So yes, the way to get something like VM_DROPPABLE accepted is to > remove the blinders, and have it be something more widely useful, and > not be a "for made up bad code". I get this part. Either the implementation is trivial/convenient/ unintrusive/unnoticeable, or it really needs to be motivated by something you find compelling and preferably has wide application. No objection from me there. If you ignore the instruction decoder part, though -- which I mentioned to Ingo could be nixed anyway -- my initial estimation of this patch here was that it wasn't /that/ bad, being +32/-3, and I didn't buy the arguments that it'd be rarely used code paths and that nobody OOMs and nobody swaps, because it doesn't match my own experience of seeing OOMing regularly and the fact that if this is in glibc, it'll wind up being used. So the initial arguments against it were not compelling. But then you and others elaborated that VM_* flags really ought to be for general things, and that as a matter of taste and cleanliness, sticking things into the *core* of mm/ is just really a sensitive thing not to be done lightly and without a really compelling reason. And so I also get that. So, I'm playing around with other technical solutions to the mlock() limitation thing that started all of this (amidst other things in my end-of-the-year backlog), and I'll post results if I can get something working. Jason