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 86F38C35FE4 for ; Sun, 15 Sep 2024 13:14:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 698DF6B0083; Sun, 15 Sep 2024 09:14:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F99F6B0082; Sun, 15 Sep 2024 09:14:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A3826B0088; Sun, 15 Sep 2024 09:14:30 -0400 (EDT) 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 266BC6B007B for ; Sun, 15 Sep 2024 09:14:30 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C197DAA1AA for ; Sun, 15 Sep 2024 13:14:29 +0000 (UTC) X-FDA: 82567016658.29.304CED7 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf09.hostedemail.com (Postfix) with ESMTP id C1AA1140003 for ; Sun, 15 Sep 2024 13:14:27 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BSFKqA4l; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726405923; 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=JtrudoSK7AIDcBBvwQPFwteXYASdpl8ORF+Y/jVI3hw=; b=iYANhrXowaXYY9FtWDWilqO/1GD4j208E4SO84y3M12b2yYB3c3VECfSX+Lx3yXSvZ+Mja n28sAYQJuTd+X5WUYotV3owOBSwJI8/MRHKn9rEEhlLX86irHbsZID03IBN59UtrlQanz7 g3u3ef8gPkyqI3THXgo2k00tWUhVrYo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BSFKqA4l; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726405923; a=rsa-sha256; cv=none; b=SBeQKK00lejQ4FwMOwGTo0BLgWbRPEZLRG7tXYTir9D6NbtyVYtptZp7Yg6StHex9SxbrE GqgUPPCLZh+7WLnM6n+9zlFaZXF5Dt37+EKt0vJU13fDtu73QRcoJO9EBaUFRxjX90T1sY fInS5HXt8l/HvcYLBNcgT9nqscT5kr0= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a8a7596b7dfso526526366b.0 for ; Sun, 15 Sep 2024 06:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1726406066; x=1727010866; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JtrudoSK7AIDcBBvwQPFwteXYASdpl8ORF+Y/jVI3hw=; b=BSFKqA4ldq9p32hgcOrHPaM/6dakHf2vZ1Upta2friB8Vm8KlkX/68Lp8BX8IjjE8k X8xrMQUvcZ+4m+yob4eRm/SGJAxrwmybiYRZ0SAstVhs9pXCpA9az2QGIfwl8HzAXF37 oZ0O5Oqsat1CdbESKze5JwBUXCLTPgdFcn5xg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726406066; x=1727010866; h=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=JtrudoSK7AIDcBBvwQPFwteXYASdpl8ORF+Y/jVI3hw=; b=aIyQ00Gqm2vUV0Ba9MBTOUBA0ICnTfBRvLl6w1TQFMwYmUN6HEop+1Hms4tujHQTkb 0du1Gs7MJgX/lIf6HonKt1GcJWfLO5v6Hyej0PaM5Z6pnaweGXrfVQtx/nKNbqvybExv hvk6vZ9HjiGKOEk5kStvQKHJV5RkW4EGuZohmxII+3G3jr1FTKj6lr39B3nDgATXg6IK X4XwauoZ0S7FcyxHGX2P/B1QekHsPk678fVm+5g8dX22P4kq2mOUXYK8dhzqKrQF4wcP glQQ1ot7HwycPHNv+DfwStfEHJtXOTiBXyAotRp4Gawx/QgCA+y/8owPRBhBamKYdanR egjA== X-Gm-Message-State: AOJu0Yxm/SKQuIaVdFPbqjGvhD9pNLhElEcD69DTcKLgeG+cfAqU1xn0 UFShhu8yOXu9j/Ccq4IsOwuEpaEDNrh0WMr/ZZJtvXT4x97WwKhpK2WOxa+ZGB2/fJuXnNHpa+j /eG55bw== X-Google-Smtp-Source: AGHT+IGtRoLFWgon6iZvoKbU7kGB6x/iraCzb4+PUz70EEcDA9G0V2GmPEcVIui8IcYqViD6nw855Q== X-Received: by 2002:a17:906:6a01:b0:a8d:43c5:9a16 with SMTP id a640c23a62f3a-a902a3d6986mr1370545666b.6.1726406065156; Sun, 15 Sep 2024 06:14:25 -0700 (PDT) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com. [209.85.208.51]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9061096784sm197109566b.1.2024.09.15.06.14.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Sep 2024 06:14:24 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5c40942358eso2115471a12.1 for ; Sun, 15 Sep 2024 06:14:24 -0700 (PDT) X-Received: by 2002:a05:6402:13d2:b0:5c4:2b18:2528 with SMTP id 4fb4d7f45d1cf-5c42b18272bmr5165967a12.5.1726406063653; Sun, 15 Sep 2024 06:14:23 -0700 (PDT) MIME-Version: 1.0 References: <8e3ffaf2-358f-479c-8de6-46e1b0bb0c5f@stanley.mountain> <58a7aebb-6ffe-4909-a7cd-d98063509a57@stanley.mountain> In-Reply-To: <58a7aebb-6ffe-4909-a7cd-d98063509a57@stanley.mountain> From: Linus Torvalds Date: Sun, 15 Sep 2024 15:14:06 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [bug report] mm: avoid leaving partial pfn mappings around in error case To: Dan Carpenter , Dimitri Sivanich , Arnd Bergmann Cc: linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C1AA1140003 X-Stat-Signature: ux858jqeh9ta16o5ny69ew71fqcsarrm X-Rspam-User: X-HE-Tag: 1726406067-735036 X-HE-Meta: U2FsdGVkX1/SlC4CPJcpOUxCKX/KgBVC3mfRKl/4mPe/0HGsOh4z2Ol1/xNf7gYiGbD/sbfMvGMYIDRro0R01QRejrPmN95fuusLhinLDl+w1dQdokLT1mVBB7UgCujQsnE6o+q/cCWvLLyXqmxakGsY/q5MywI5SR28PLUqgndXwbv30NizYPN4SQ6+GgHpagCbMu1QtXnQ4KLqf5E/kZ6QVuNx8uhNIgRHqbDBu5LKIs6Us4fKe95H9Be3IFPfNFKOptLWs8cvMk7Woa+njTSjzHQnd2HhrEfUQI8/A3Vu/oX63vXX98cfga2/L2iK9Y/V2gr+SCS4bSeSSSs92wUb4l58Bx6PwjBkFePfO2ET9NHv1Pvq6Y7gZtdjCmYo73eV+EGd0bru2b6C1RQstpsPLjTMTaiM1FCZE7Xw+Azxr5r8XnW+Yij87CvOwTyDhEJrg2EPbDQ6UZxwEoD3GgWkxSKYHzvrPz7FtD1S3OQ9duinw2atmr61iPaWMWZLMIKFDshsQQGYIwDcOQzt61SYFJ5kLzuph2D//QLsP97iCLIZ6LIvHpan4VTE76j0rXLBQ36tAEo8iF+REzNnORBDJcK3xoVbiZMouYmIk89UP48u1XXAHbjlscC8RT0iN3mCcxH6BtL4gLUBQ6LcZ1O3mhDVxUawOls3xIsQATcgrqPJwyL+GISj4cZlkzx1DrrVHaHyqa+aV7iKAsQ/Eq8vJKkRHyTgBjgklLcu1k0Wa6WqLAPXOdfvE7ddgDq/853sLKvd1Wi/isJZqRSuZwvSP8ZPtES9BxJ2vduwPuapFXDskuMK9H+0giRpiqa2igXtoP9f7Am1yljjlPB9fd5slpYzAw5IaCt8NGCsbPAufeFh75q2kco1Xj9g1Kzo+evO1bYeBqNowQtXZbIe7Ccd5z87Ln/4MC4unlgxJ3jCBLZLA+HKvZjUZLAYzL2ZjIw+PXshnb0SS2Us/fD 62YFEPZf k27EOo++oXpD3ZsvC4qSP1lTHvZIUOA4FDaKt8e3hgMha/2/zfWo6UgXxY5JeJj0h8xMCc7Ptq2NnGSlPGAoDZBVfpfA3mWWdcU3mJ3mxNWREFGyJ4+VJK4os6a9u68r40NwTegzzTl5lmXqPSVm/Q2jOPSyNypki2zzH8nZDpBDgf3O55kG5ooQ0VbAEKnuYoySk7hz/wrMlBi+OFNgTH4K/GWl9BRrmz6S0aG1vlQhS8ROtKUw/MdG5sv2m+lq3DCkzxucrfw/BlidCAm3O7WXHbaTrENgOEGGgQcKozQQb2mClWuiuaVN6/plaYsCuH9OJfm1oaQdOSOU6P2wf+fXi3AMMz+npeH+tlaB8FoaDucYwrYbaL+6RfVXA+q7mFZV0cBm5qJqesBKg0UGykwMFvNMnk0/MuhruaAVvrn1fjrhMx1UK++etWk/mab19tlkt2eDHDGXpBoJMZfBzVwvfQhcR5quaSx+RbQMdOZQS6SBLdHBO+m/jN7oajGxZO2S+MIMZVKzdhIGMNX3tMSfclvp8/x0socldJ+FIPxJ9j1kH7fbA9F4jJAQdungLSrpp 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 Sun, 15 Sept 2024 at 14:05, Dan Carpenter wrote: > > Yep. You're right. Smatch doesn't count allocations as sleeping when we pass a > variable to for the gfp flags and those functions do "get_zeroed_page(gfp)". > I've been intending for years to handle bitmasks better but I've never > implemented that code. That explains it. In this case, the 'variable' gfp values are basically identical: GFP_PGTABLE_KERNEL and GFP_PGTABLE_USER depending on which mm they get allocated to, and both are just variations of GFP_KERNEL (with __GFP_ZERO and a __GFP_ACCOUNT for the user case), so the exact details of th egfp flags are conditional, but they are unconditionally sleeping allocations. But yeah, if smatch doesn't follow that kind of conditional gfp flags, it explains why smatch thought the odd gru_fault() code used to be ok, even though it clearly isn't. I'm not sure why gru_fault does that preempt-disable at all, since the real locking seems to be that >s->ts_ctxlock mutex, but it has done it since its initial commit. And it's been very much wrong since that initial commit, but I suspect it never triggers in real life because the page tables probably are already set up. Probably more importantly, it doesn't trigger in real life because SGI UV machines with that GRU hardware are probably hard to find. Anyway, maybe somebody can explain why gru_fault() has that preempt_disable() in it, but it is very wrong. It always has been, and the recent change just made smatch notice a new case. I don't actually see any reason for that preemption disable, and I suspect it could just be removed. But maybe somebody else who knows that odd driver can pipe up.. Adding Dimirti and Arnd just in case. Linus