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 2BBD1C46467 for ; Tue, 3 Jan 2023 15:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A9398E0003; Tue, 3 Jan 2023 10:01:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 658DB8E0001; Tue, 3 Jan 2023 10:01:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 520D58E0003; Tue, 3 Jan 2023 10:01:34 -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 444618E0001 for ; Tue, 3 Jan 2023 10:01:34 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0504B1A0B26 for ; Tue, 3 Jan 2023 15:01:33 +0000 (UTC) X-FDA: 80313801708.06.FC6BF61 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf22.hostedemail.com (Postfix) with ESMTP id 168C6C0002 for ; Tue, 3 Jan 2023 15:01:30 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=ZEU+QTFd; spf=pass (imf22.hostedemail.com: domain of "SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 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=1672758091; a=rsa-sha256; cv=none; b=T42d1FZVTRge8GVfIxOxhEOfonPmaVPzKKV9gBsv8pXAMd2UzjUpWLLJRlIvtjSW0+pVB6 U/Y6Z+GJDxaD3+fAMxxn/00A1PC54dcwKbMZ1oR/vfKzLYgGF1tKotZkpjLu6rGV4WX7xA tGZNr2+jZ0gf5ZYny7baGaryicvG5j0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=ZEU+QTFd; spf=pass (imf22.hostedemail.com: domain of "SRS0=kn2u=5A=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 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=1672758091; 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=1Wi9ZRVeh3Pac9gdkou/v2cNOa31fCafYfyWUT3Kr3k=; b=UfgSmF7ZWnewAnhtFG7UrhHqBOR212RTRWCSomeCGR0Vt0kGtnmXrZkSKr7O7cqvRBpZjt qDAs+dD9j6LpAVKNxVEO2wUT9lNIsxx+3FpJffyd8EPU42w9qhUjDW//2H/aOImitw9zak guP7wjkT5Ebi7lbdpl/gTDb+g6/qq3g= 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 1BC5DB80F9B; Tue, 3 Jan 2023 15:01:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32045C433EF; Tue, 3 Jan 2023 15:01:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1672758083; 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=1Wi9ZRVeh3Pac9gdkou/v2cNOa31fCafYfyWUT3Kr3k=; b=ZEU+QTFdcn8/wM4uwmRXY0iTfeJnw462+uvwVijCHAYTRzMEM9X/fGwuq4H0hB0+vdAWUN 0SpQRZa9aIrwhFWWESP/keVgBqliMvdVcIE7ybqRBGR/tZoWvuQL52s0/l/9CZfvo6pWQl HrwsOL4AmDFm2NFf1S0OS9Y2pYyvu4s= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id f7395740 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 3 Jan 2023 15:01:23 +0000 (UTC) Date: Tue, 3 Jan 2023 16:01:20 +0100 From: "Jason A. Donenfeld" To: Ingo Molnar Cc: 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, Linus Torvalds 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-Rspam-User: X-Rspamd-Queue-Id: 168C6C0002 X-Rspamd-Server: rspam01 X-Stat-Signature: pcmbnxh9urwbz15z1efg1a6ygegyrt5d X-HE-Tag: 1672758090-42584 X-HE-Meta: U2FsdGVkX1+vRCS85pNW7nPquqpRFdmj832+raXFUlIrK+let7MTteLYk7D6dNdbbpkHsGbVDjRfsR0jOr6ktUqFyj3vzhnBT0J+LkiY0XtQEkw65Wb+tbIp/ulpDJKEmHElpyKjq5xi5183XkURhdhjfbOPnvHuqOVkBncwbZUeZ46CY2oVMVnnqaiy3GnJrtdzuMr0lbUoerjQCTkD8MU+5PHjaxbmd5vUpLOTw9htb4euzPG7StlZmW9KkrkokVMzBC4XSAkb5v4aLjCBgtw2+udQu+MxOhSzTqOAYZrnwfj9arpKS1CnHMaadEDESx+lV+oIId4wYvseSDSblA9842GRJ0hJZiHsN9EM5KZ7BwXxm6M0ggg5WNuFNh+OJf2/LTwnk+E0sbZK29UL7hcMXBHwrds95/tV1Yuio8SGKjfySYnR+jgtsMSzev77O8A/TAgB1T4g+SMXmg7x+DEGlVVisZ3fnkcR0niLMChkwKxZpS1aURHWybOlSprWrGflihYRXWWxNk+UcICjjaWYzTH5LgtZ08McWLi2fj1Bs7+U1gjYyJSfPFlz+PEtYUoIaM9Rf8o1OJ7wKTU5t91FFmXC7hJVpPtG/3/OlPShsJeFbdoOe/U0KE7c/8u7lm184ZVbOcqs+otrZYD2nNfMXehN13ustHsg4uUN/9FpY8xM6MGUNv9vjgF+lBmSeWCqeQUu/O74+bgy8Tt8TpJ29pzVQaFzNjiHZoV1GISbON9bfjieNc6Nv31sBBt+FhUzbr7ALogyRs9wqfOIH243fACiRRPIzdu/DNTu++wocDND8OJZ3EtviKaoLIlWD3JCoEXMYRo5TyMvO0UGbvGKZd3U8O7CK4hRkn/cwtMSCxYXrHWPXhqEPEnMTcymaSAK+3p0WqwCPX6fWx+naD5rmKVbBuT0L6wBlDwhPtFyGL3P32U03jcnVkwJsjAXdpE0G+el8RwZL98+yhA 6ESvKFJ2 nXa4yBgKpeUHsV9RU2AiPKaS69fp+X9bckCQY0B/T0EfeECTI6yh4Xhylyugg6/hY4Cy0c2uBqCetE8BT0Pz0Vek6d8OpKOXeMjliq2aeQ+na44cKv7v3dJliXgY80mThvx63hGmYJAjbuJpXP0H3s5xxaxER7fDrp5ovkbQvAhSAuosSoU7E0/RMiS3pDQdWQxz7xBJyOExog1tvXL8Gv7I4EkuRkeK7EVqYzRvTfffndubpp9rG7V1bBYdpyE7HWXiZiqzUlcnGlGE= 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 03, 2023 at 11:50:43AM +0100, Ingo Molnar wrote: > > * Jason A. Donenfeld wrote: > > > The vDSO getrandom() implementation works with a buffer allocated with a > > new system call that has certain requirements: > > > > - It shouldn't be written to core dumps. > > * Easy: VM_DONTDUMP. > > - It should be zeroed on fork. > > * Easy: VM_WIPEONFORK. > > > > - It shouldn't be written to swap. > > * Uh-oh: mlock is rlimited. > > * Uh-oh: mlock isn't inherited by forks. > > > > - It shouldn't reserve actual memory, but it also shouldn't crash when > > page faulting in memory if none is available > > * Uh-oh: MAP_NORESERVE respects vm.overcommit_memory=2. > > * Uh-oh: VM_NORESERVE means segfaults. > > > > It turns out that the vDSO getrandom() function has three really nice > > characteristics that we can exploit to solve this problem: > > > > 1) Due to being wiped during fork(), the vDSO code is already robust to > > having the contents of the pages it reads zeroed out midway through > > the function's execution. > > > > 2) In the absolute worst case of whatever contingency we're coding for, > > we have the option to fallback to the getrandom() syscall, and > > everything is fine. > > > > 3) The buffers the function uses are only ever useful for a maximum of > > 60 seconds -- a sort of cache, rather than a long term allocation. > > > > These characteristics mean that we can introduce VM_DROPPABLE, which > > has the following semantics: > > > > a) It never is written out to swap. > > b) Under memory pressure, mm can just drop the pages (so that they're > > zero when read back again). > > c) If there's not enough memory to service a page fault, it's not fatal, > > and no signal is sent. Instead, writes are simply lost. > > d) It is inherited by fork. > > e) It doesn't count against the mlock budget, since nothing is locked. > > > > This is fairly simple to implement, with the one snag that we have to > > use 64-bit VM_* flags, but this shouldn't be a problem, since the only > > consumers will probably be 64-bit anyway. > > > > This way, allocations used by vDSO getrandom() can use: > > > > VM_DROPPABLE | VM_DONTDUMP | VM_WIPEONFORK | VM_NORESERVE > > > > And there will be no problem with OOMing, crashing on overcommitment, > > using memory when not in use, not wiping on fork(), coredumps, or > > writing out to swap. > > > > At the moment, rather than skipping writes on OOM, the fault handler > > just returns to userspace, and the instruction is retried. This isn't > > terrible, but it's not quite what is intended. The actual instruction > > skipping has to be implemented arch-by-arch, but so does this whole > > vDSO series, so that's fine. The following commit addresses it for x86. > > Yeah, so VM_DROPPABLE adds a whole lot of complexity, corner cases, per > arch low level work and rarely tested functionality (seriously, whose > desktop system touches swap these days?), just so we can add a few pages of > per thread vDSO data of a quirky type that in 99.999% of cases won't ever > be 'dropped' from under the functionality that is using it and will thus > bitrot fast? It sounds like you've misunderstood the issue. Firstly, the arch work is +19 lines (in the vdso branch of random.git). That's very small and basic. Don't misrepresent it just to make a point. Secondly, and more importantly, swapping this data is *not* permissible. It doesn't matter if you think that certain systems don't use swap anyway (you're wrong though regardless -- desktops will swap things pretty regularly). It simply must *not* be swapped under any circumstances. It's not that swapping is simply undesirable; it's absolutely catastrophic. Do you understand that distinction? If so, then if you don't like this solution, perhaps you could mention something that accomplishes the goals in the commit message. > The maintainability baby is being thrown out with the bath water IMO ... Really? Are you sure this isn't just a matter of you not having written it yourself or something? The commit is pretty short and basic. All the actual internals for this kind of thing are already in present. The commit just pipes it through. > And we want to add more complexity to a facility people desperately want to > trust *more*? [RNG] That seems like a ridiculous rhetorical leap. > What's wrong with making mlock() more usable? Or just saying that "yeah, > the vDSO can allocate a few more permanent pages outside of existing > rlimits & mlock budgets"? Did you actually read the commit message? And now you're suggesting a rlimit backdoor? And adding more cases for fork() to fail or block? That sounds terrible. > The rest of the series looks fine to me, but this special one of a kind > VM_DROPPABLE is just way over-engineered cornercase functionality that > pushes us well past the maintenance_overhead<->complexity trade-off sweet spot ... I think you should reevaluate that judgement. Consider the actual problem. I think if you look at it carefully you'll see that this is a pretty straight forward solution. It's deliberately not over-engineered. It uses existing facilities and just does the plumbing in the right way to make it work. It's really not that complicated. The commit is +38, -4. The commit message has more lines than that. Jason