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 28A43C38150 for ; Mon, 8 Jul 2024 01:59:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 822B56B0083; Sun, 7 Jul 2024 21:59:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D34A6B0088; Sun, 7 Jul 2024 21:59:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69A776B0093; Sun, 7 Jul 2024 21:59:56 -0400 (EDT) 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 4D92A6B0083 for ; Sun, 7 Jul 2024 21:59:56 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BB0178106A for ; Mon, 8 Jul 2024 01:59:55 +0000 (UTC) X-FDA: 82314929550.22.7C8D6E4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 04746C0005 for ; Mon, 8 Jul 2024 01:59:53 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=M54NpJDR; dmarc=pass (policy=quarantine) header.from=zx2c4.com; spf=pass (imf10.hostedemail.com: domain of "SRS0=B+7m=OI=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=B+7m=OI=zx2c4.com=Jason@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720403970; a=rsa-sha256; cv=none; b=YxMuQB0RsrKCgzOLjLOCIPvVO5fM/VXVQDTqoJwXeQna4QNtDfuTaByLjBuIEEDOkJDLQO uKQw5zEtNxfi2Gp3Zv1Qh1Pz4bx1m7yxaDHlxni/n+zpyT1YHTijf5dN2ALKNpAInXVlGy XQxQZBnrfHpnQl3ExlnFCmMz9CNgeyY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=M54NpJDR; dmarc=pass (policy=quarantine) header.from=zx2c4.com; spf=pass (imf10.hostedemail.com: domain of "SRS0=B+7m=OI=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=B+7m=OI=zx2c4.com=Jason@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720403970; 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=n4cCQuWztdSIfQ492l8tJFqxNnyuIv8Y+chaiokzYoA=; b=XQrAqklKwpo+m8DW2+1tLHt/jirvTq+R2f7/2im/DDss4dXfA10A2YmSURaVuF1vaGOAEt 0pQlXegBR79uNSTC+XHt7uRQgCogUhkO7/byfnvDepVPpdxN435+SKskhr2YYIAH6Aw1Ms hvWBK0Gp0DvGss8BshbGnzeRE+kAv04= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F38B260018; Mon, 8 Jul 2024 01:59:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 090D3C3277B; Mon, 8 Jul 2024 01:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1720403989; 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=n4cCQuWztdSIfQ492l8tJFqxNnyuIv8Y+chaiokzYoA=; b=M54NpJDR8YpmMAE0NIzO6pSjJl2GHnspS2wmlAMkCkFYGRuEM2dCuP8ZaJ/lApAUjoHcqp pp4OL+s9vycmz0NNLn/LuMMNJ1Dwn5+CF1j2EuVasciiWTB2jHTkUGXpdtkfqp/7jEQq7X SfBAwl7CJD0+pqrAIANMGiWYoLN1I10= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 9f6d4916 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 8 Jul 2024 01:59:49 +0000 (UTC) Date: Mon, 8 Jul 2024 03:59:46 +0200 From: "Jason A. Donenfeld" To: Linus Torvalds Cc: David Hildenbrand , 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 Subject: Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings Message-ID: References: <20240707002658.1917440-1-Jason@zx2c4.com> <20240707002658.1917440-2-Jason@zx2c4.com> <1583c837-a4d5-4a8a-9c1d-2c64548cd199@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 04746C0005 X-Stat-Signature: fomc5f89tet4dzwaxt4edcf4ihwxsypa X-Rspam-User: X-HE-Tag: 1720403993-207566 X-HE-Meta: U2FsdGVkX19hBfjKMQQjx9+KfFI0Nh3sbwHEWrsITOXFAohAAKiDZysvTbfARc+gEmF0+b/XPVZy7bXwmzCtmJvmFqIACPClKTerXmpF1ZkaB6TNAbh6KxlCnuL6i5j9u/5euGOmuKZVPSE1TnjARcYQEW3UQ1EhOWV7PGBfQ2jJ1x9FnfLKGNwLEt6FByTTNcaTeF5FkcOWOIix5x96uY+8ELTgaWqQZEl55S9yYywJ81K328nl2DFWR8zL7lf4XE94TeUbGlvUdYtzEGJvTWlZcpCuZtPq4d8dafa0S6DDyx15OvuesyZSivVgWRr3yRtJ1/BAdNrB4OjUoTZeT82AITnQD1hFLTL3CkG8UA+E5PQ44VaytpMKo08yjiFwaprAaR/1v2k4FpLzp5KhoNVIzOKHEMTg5GvMItx85qGDSAsxC99uuUolF8YpsBT128wTiASB/11V2lEOfbJWIvmZhcJdvFjAy+UrDU1erRKOHywBpkM6eIo8A8ANiVtogi2JtnLCZN4Un9A0VYorLuqSKpe6FyX0KChPTzSoIgVjQ1Kscnz21McIJfq6AuK6HbyFZhPZiZqPC9D3cm1j6aKkUey9ds14TC1DfS+3Ou5lNFGjDNm6aafV/wL4j/Mi92O0kZtO8yRIZWPATbTBj6LLUUM4BMe0Ng7dqbQiGdkjWVr9/XEMFk3qsHhHJ/W30oqXrDYwqgG3nuPZU9Of9OgIoNu8U5HmA/6nIbBneaLn40hEd+EoawgyZNugpg4Cl70Rcyr6wXujJUQr39QPRt/AS3m6UpuTeLqNuk34R4mGas3n/wf0BLp59an5PbcFR/PoF5wiYqfSlgcbraTXxm8aSuxywp8jTMKwBZvBr4GLVL3dZharHV87CBOSrT8bJl5fHF/Jgqfx/haGvlHiFMjqnyI8KYiGKOCBWS/D9PlpsdoSIJEp+xV+nKz2XHGyHxnBveWfHbtOC4iGCE4 1mjxSeoo 05ODGwS4Un8AuZMni8hKUtBOT3uk6qj6JiVjtgVXVlxAukm0gWTVphwBpfdY+1tzBfaHsXX3WiSx5zbnM/bdkp2a2wvjylA0W4qscyD2nIaGDxXvYdlxczu4XCs9M43uF92lUwKHPPBhL7nOgVD87WYlVefYFxsJlgB+t+ak8qN5NKVfRhPyF6j94f49AHD2sDHynA0Fta0zEGddnDXfCCstMQQoMhVhoDCJ6+RGG+ox+RKvY5KjHVGJXalg+JGBtt27ydA2ipVt2Cy/FzGLZszXg7jf7RKq+Cn4YePOaSPfFvmvZudXlOq1q0kJk9rfxSmaAXC3gU+C35iF4LC4+ZC5I3YcDlTfK4cTw938I9MJoXYlCa1w89brXttlxGZtgOBPWAorH6XLppiMfK0EP3gx5eYpgGYQisVDhf+4QDjBzMUxUc4LKHVx+Q7q52p2UZi/8BlIYaO2Dl5U= 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: Hi Linus, On Sun, Jul 07, 2024 at 11:19:46AM -0700, Linus Torvalds wrote: > (c) we could actually use the PROT_xyz bits, which we have a ton of As I just wrote to David, I'll move this to PROT_xyz. By the way, in addition to the PROT_SEM historical artifact, there's also architecture specific ones like PROT_ADI on SPARC, PROT_SAO on PowerPC, and PROT_BTI and PROT_MTE on arm64. So the MAP_ vs PROT_ distinction seems kind of blurred anyway. > 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. FYI, I looked into using VM_DONTCOPY/MADV_DONTFORK for my purposes, because it could possibly make another problem easier, but I couldn't figure out how to make it smoothly work. Specifically, a program has a bunch of threads, and some of them have a vgetrandom state in use, carved out of the same page. One of the threads forks. In the VM_WIPEONFORK case, the fork child has to reclaim the states that were in use by other threads at the time of the fork and return them to the pool of available slices. In the VM_DONTCOPY case, that's not necessary, which is kind of nice. But if the program forked in the signal handler and then returned to an in progress vgetrandom operation, now there's a signal that needs to be handled internally, identified as belonging to the internal state areas, and not bubbled up to other code. This seems difficult and fraught. It's far easier to just have the memory be zeroed and have the code unconditionally check for that at the same time it's doing other consistency checks. So yea it just seems a lot more desirable to have the behavior be zeroing rather than an asynchronous signal, because code can straightforwardly deal with that inline. Jason