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 ED18AC25B75 for ; Fri, 31 May 2024 13:01:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62D1C6B0098; Fri, 31 May 2024 09:01:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DD186B009A; Fri, 31 May 2024 09:01:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A4E46B009B; Fri, 31 May 2024 09:01:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2C9666B0098 for ; Fri, 31 May 2024 09:01:12 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D427BA2D01 for ; Fri, 31 May 2024 13:01:11 +0000 (UTC) X-FDA: 82178701542.11.5839475 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf27.hostedemail.com (Postfix) with ESMTP id E0A284003C for ; Fri, 31 May 2024 13:01:08 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sUxyzC1X; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717160469; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vRchOj1ggC2TIQN8s7PjJT+YjUNxb7bVoZD51wfkss8=; b=WHAFSOYgo+f1euyBdinVfCI4wCqHSm1N7xHvrocht0dSTMqA/WRVecoV8msUiqLE5xwZ6T 8BTyr2vc0j5EbIj/rB5Tg5ehqUhTN+Tasfpd5Gdnxq7FSjPAz7HdjXwfOku8j9L5F0GTUU AO+nQ+2QKIPTRXnxWJVP4hdN+y85bA0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sUxyzC1X; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717160469; a=rsa-sha256; cv=none; b=qYOOCTE182s0CtqAlyUMvVBkwS9qtrHr4qiyHjpZSv7tmD2xvc9vP1PtvEXloMtb70COow UfpCJpOASjX4ij/grRoIf/T0LIvgoZUg5bB23W3rXFszXpBqI8LD+VIBwBQrY04MnBAEUt ETb88GKIeoKQM2CNXk1TqtNIj32F9RU= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5750a8737e5so14067a12.0 for ; Fri, 31 May 2024 06:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717160467; x=1717765267; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vRchOj1ggC2TIQN8s7PjJT+YjUNxb7bVoZD51wfkss8=; b=sUxyzC1Xq61LEYNdRtUPgZcEis0PLZLYMq0vrnhq+ARB0hetRdxaQjPgGgBKjm2Vnm K3p77cXu+giPedmzRRaT5l1hdDpImGpkuhP0/7HupsX46nox3dB+65bDi71DAtv1ZPWs A98pE5QIa/pXADzyWTJXhH/VkGvtkhRf05ofQYOYcc80tyRGaLH7hMwxhJpu/M2ojgbf hR8wFsr0lFySOr3xHuW/NbzcwUBawx+7+NURDzKFzwauvBDFJ+qIfjRSs171TRCHZ+LR TBu03/C12l0scZcUXhybTaj7ETmZNY0NiK+eskgxgMwjYss6gguK8a/C73HlyzbOmNQ7 e/uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717160467; x=1717765267; h=content-transfer-encoding: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=vRchOj1ggC2TIQN8s7PjJT+YjUNxb7bVoZD51wfkss8=; b=YD1RchS5gMwsAHJISmp62WBhEE2i1ZoLbgUVUJU0+6wM4euu1fqZAYKwyDUgB8MZGs 1zpVHuggtO+eeEWtHS+msSU95Wmxf4t/tNbnXr8ydrl7xq5HekeVMTcP5DafX+qrUl2U 5oWGfPLeSyHS6C35OLleMymnaamauDbWzUeqZu3qal4qTNVq5evEP1vyLoZUbuQgUA1n ArAsFgu14DS54S9LjNLKTAog/V313nU6yyLwNyqbglVSWof3qkiwUTwlgFwrTPciNG9Q 1KN8+PUmBV/pMVc1QwVFeVl81I5uDm4yyeALUF9xaH4Uy2j5mc8zCFCo0f7t9KBqekR9 evHQ== X-Forwarded-Encrypted: i=1; AJvYcCUZpqKpBjAk8dNK7fnFZcN4WBE6tzYENkfVLQzp2QOket010rDj6qX1a8lSNXQEN6lETBKob9DMPcYeMvyZXKot4z0= X-Gm-Message-State: AOJu0YxMDXNiA2BWb5EzUCgyvIDOpCNtsjGGBxrb3wh3WKf929+jn2CV 4xkEU5I7QBaMNZN48ObeamMvjBN+WHj4/DKG1AEp6GiXZgXHq2eAyVPk7UqWmTMbzRifYuOM3pC lAb3zbu90L7Ghy/QaHoCXb1qIU1qWrEoqVK7E X-Google-Smtp-Source: AGHT+IGyobXtF/ORS1N/GztNIrOHPwMv9FM8zg9fZE3Hz3rHQXNmWAty6aJ8lRd6Vdl/KOtZJApkG+sJ4f7FFcdpcvU= X-Received: by 2002:a05:6402:2932:b0:57a:2eac:cd4d with SMTP id 4fb4d7f45d1cf-57a378ff925mr106485a12.5.1717160465623; Fri, 31 May 2024 06:01:05 -0700 (PDT) MIME-Version: 1.0 References: <20240528122352.2485958-1-Jason@zx2c4.com> <20240528122352.2485958-2-Jason@zx2c4.com> In-Reply-To: From: Jann Horn Date: Fri, 31 May 2024 15:00:26 +0200 Message-ID: Subject: Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings To: "Jason A. Donenfeld" 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 , Christian Brauner , David Hildenbrand , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 5415tpe7sdxo63p8c7qgczdc8uin1e46 X-Rspamd-Queue-Id: E0A284003C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1717160468-757997 X-HE-Meta: U2FsdGVkX1+4izFdjvQINNP6gpRzwz9Ye2EbjUpuVrhNLGY015bWMSjEdOS5Bj6rGxZDMEiXI6KmqYldd06RICFwwSOLEEV7huuqFDREYdu3xVVMrLU78O8cH0Ml5SA3/OcOi5I0JUDy9AR//jjTZCJyl4wcS9J/u35+bMM49RX62B9q1ofj1ZTotcYNE9j3oaf07F+3f9busu132XohjXh8WVdNuejroQ/MAZj4YYgZzkwUG2damvULoGmZw4NBFf6cTuoPFo+gOXmuhRm9Q5dllrE3XIezXWLWUrxOCPxLcM31JxShRMLFsK13rrOSN/ZoVLhE89ov5Y9GEhhnOiYJHfqMhGG1ChzQeOXjF1SG7UDUGI5TgF3wH8b1Co/Og/uQ7QjpBe1sCcKeh4Hquo5nWRGmYsdu/qZsGA/BS6II41S33ohQc08I4yJYPJLZx/8vhxDuHqa7dYxh1GCtc+O9pqTIVypwxcqg6NFL2i/k43R2xIoZJMBM1/KBeRI6dtiVNafDRZyc0oHPetIXeiOY2utZjHTKfauqJLO4DejcEX/M3+fVJ8m8SCjCopOvqSS9FftC21HXEN+rj8DdX5kI4VlpM1Qt5Y5Dey+1KwxcZagJItNjdrq7PQiwdvQstSiJF0rIDiqmz+bz8GkzbHcd/ZBPZbyFomPGE+GOV8TbyYCfLOAz5paIiOoeRjRcr7ZF2uRdSyWq5tpCm3+qune5WS0GZse+Q8odKS/l5B1futhRzuVVPz4SmeYkN1rsDS1gvsFRk37zJ54qvvniTq9XaH2rlR5zg78eZIuWoUJ3wrefsDFw3oz/k+qLX7A+dNAhVrwRz6VE4MX2s3WRE53112eGwWddmFC9UdbMWNVjgSNaUJBrO8CLvF4lBwVJRcr33FtGOp7PBg7cqRzkEIl8y+YH66ofAoka2qB9+bOwAmc3ZZ1tqBTCHQ3C3Q62aphLfsc0rifu8/Rfy3B LFxoWcgJ nbKXvzf0K87oh8QZ6lLlWosBLWMHGHLSwdMNsPD9lg4EypL33gz5bTG5bH++NIHXwBW4kyu4wgqc1hfIdqC8NYQ7Ec1/MuQ9BWCjO0W8M9yPvtrPdShWDUbdW2EJZBOXvSpV4T/WdJdcQ9tWcHK24YSUjuDurSErPbBBDKgE3H18YLxapw/qSazwgsLLNVopjoRlaoSdPwnyc9Bz5cgvKE2D272tDLlWHycDQRX+HdHGUgDdwkINMOpWEEhpizBFePxC/Ky1n4LsRyQaZxP4TnkbSR4vrofjThVq3j3JPk9l+b3dFo9ZZA7H9gUKzTM79Nh+OW8bPdqzVX7Q= 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: On Fri, May 31, 2024 at 2:13=E2=80=AFPM Jason A. Donenfeld wrote: > On Fri, May 31, 2024 at 12:48:58PM +0200, Jann Horn wrote: > > On Tue, May 28, 2024 at 2:24=E2=80=AFPM Jason A. Donenfeld wrote: > > > c) If there's not enough memory to service a page fault, it's not fat= al. > > [...] > > > @@ -5689,6 +5689,10 @@ vm_fault_t handle_mm_fault(struct vm_area_stru= ct *vma, unsigned long address, > > > > > > lru_gen_exit_fault(); > > > > > > + /* If the mapping is droppable, then errors due to OOM aren't= fatal. */ > > > + if (vma->vm_flags & VM_DROPPABLE) > > > + ret &=3D ~VM_FAULT_OOM; > > > > Can you remind me how this is supposed to work? If we get an OOM > > error, and the error is not fatal, does that mean we'll just keep > > hitting the same fault handler over and over again (until we happen to > > have memory available again I guess)? > > Right, it'll just keep retrying. I agree this isn't great, which is why > in the 2023 patchset, I had additional code to simply skip the faulting > instruction, and then the userspace code would notice the inconsistency > and fallback to the syscall. This worked pretty well. But it meant > decoding the instruction and in general skipping instructions is weird, > and that made this patchset very very contentious. Since the skipping > behavior isn't actually required by the /security goals/ of this, I > figured I'd just drop that. And maybe we can all revisit it together > sometime down the line. But for now I'm hoping for something a little > easier to swallow. In that case, since we need to be able to populate this memory to make forward progress, would it make sense to remove the parts of the patch that treat the allocation as if it was allowed to silently fail (the "__GFP_NOWARN | __GFP_NORETRY" and the "ret &=3D ~VM_FAULT_OOM")? I think that would also simplify this a bit by making this type of memory a little less special.