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 B69C3CDD55C for ; Wed, 18 Sep 2024 21:09:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9A056B0092; Wed, 18 Sep 2024 17:09:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4A1A6B009A; Wed, 18 Sep 2024 17:09:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C112B6B009B; Wed, 18 Sep 2024 17:09: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 A3B046B0092 for ; Wed, 18 Sep 2024 17:09:12 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 389591C4FDA for ; Wed, 18 Sep 2024 21:09:12 +0000 (UTC) X-FDA: 82579099344.15.A0F481A Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by imf01.hostedemail.com (Postfix) with ESMTP id 4A0A340009 for ; Wed, 18 Sep 2024 21:09:02 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=hpe.com header.s=pps0720 header.b=kuNjuwwa; spf=pass (imf01.hostedemail.com: domain of sivanich@hpe.com designates 148.163.143.35 as permitted sender) smtp.mailfrom=sivanich@hpe.com; dmarc=pass (policy=reject) header.from=hpe.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726693685; a=rsa-sha256; cv=none; b=tQV6JM3S/jiX5mE4ZNT5k2W+Gg2FmTYgWnmb1SpUTBBAg++3WP3M4s+feEaOch5Uu7h5qL iDXoFqp/w6nBA+DE28eio0L813LzJ/7wOIWOMpYZtd+UFOK67iY6WLiInd9gmRGJdVN4OP YnkN5MFF1NzMyldTFMnrdMM4NnC1dBE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=hpe.com header.s=pps0720 header.b=kuNjuwwa; spf=pass (imf01.hostedemail.com: domain of sivanich@hpe.com designates 148.163.143.35 as permitted sender) smtp.mailfrom=sivanich@hpe.com; dmarc=pass (policy=reject) header.from=hpe.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726693685; 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=YUfFQ/mdIxLpiE4qW8x9kAuqfbzJ+ESEjUTDQuMY+Y4=; b=SRXE4fyvriyGYN5MpwRPZDAGDPhjj8JpYNBbfZWNXNh40F47sFWXqQPJGzZIZSTtl9Xtpz 7zkTI96TuvV2KfH2rRu5cvOuzLm2FC/KXlHjJfAiss45Nr8EjBnS1TxyjSMEH3gcOkZELV RNukjN6vnKsW2Oh2Nu5gzqcsEKUDND8= Received: from pps.filterd (m0148664.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 48IHoH3u019473; Wed, 18 Sep 2024 21:08:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=pps0720; bh=YUfFQ/mdIxLpiE4qW8x9kAu qfbzJ+ESEjUTDQuMY+Y4=; b=kuNjuwwayvmNZRBD9q/iW0GQw4ZpWHmWscorELB J0iVJAWfAx2zgvVdIv3+4w+3TlnzqOxAvup/5wQVE1c+JoH3eaM9amBxwBg48/me UFqNBW0T9XENgrul00NxKoU+Nk9DBl+Tf7vYOxEZoi6ec2eXbblFEeerx3uExdZt L93YdPvsvWMoV3RrbCwQ8PMDahhhX1Ot/T9R9UoL30Mfv5oypHze4OxMnzteiGx7 HcqkUDXnUQCTPfzov0D4hCeqfgEZ7kOt8KpHd+Znph8QzetkkxLCgBQErM+kb++k yCTnGCeYG44X1X95GTc25Xdbce/tMQHCOhEqnCtDc7H4/zw== Received: from p1lg14881.it.hpe.com ([16.230.97.202]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 41qvjhwkqa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2024 21:08:59 +0000 (GMT) Received: from p1lg14885.dc01.its.hpecorp.net (unknown [10.119.18.236]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by p1lg14881.it.hpe.com (Postfix) with ESMTPS id A2357806B15; Wed, 18 Sep 2024 21:08:58 +0000 (UTC) Received: from hpe.com (unknown [16.231.227.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by p1lg14885.dc01.its.hpecorp.net (Postfix) with ESMTPS id 22C638014FA; Wed, 18 Sep 2024 21:08:56 +0000 (UTC) Date: Wed, 18 Sep 2024 16:08:54 -0500 From: Dimitri Sivanich To: Linus Torvalds Cc: Dan Carpenter , Dimitri Sivanich , Arnd Bergmann , linux-mm@kvack.org Subject: Re: [bug report] mm: avoid leaving partial pfn mappings around in error case Message-ID: References: <8e3ffaf2-358f-479c-8de6-46e1b0bb0c5f@stanley.mountain> <58a7aebb-6ffe-4909-a7cd-d98063509a57@stanley.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Proofpoint-GUID: 9tUBbpDz8talXEkGopIBw1n0wrn3KCrS X-Proofpoint-ORIG-GUID: 9tUBbpDz8talXEkGopIBw1n0wrn3KCrS X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-18_14,2024-09-18_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 adultscore=0 malwarescore=0 clxscore=1011 priorityscore=1501 mlxlogscore=511 suspectscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2408220000 definitions=main-2409180138 X-Stat-Signature: wtj79mfy3izriiheaqdnmo3dxnxnr1xk X-Rspamd-Queue-Id: 4A0A340009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726693742-217146 X-HE-Meta: U2FsdGVkX189QoQhS94wVKJq9Mg0eRRjLVYCV6oytlIS8L8XyPC3c16eaTmtMCi/2zT0IqTHEMNMi0paYzweIsZXtHRglwnToL+9ax6GcxhVRl7blA7ciBrY40lnBdwOKnAzYwaGmhmunxtGX/h1tipj3RaZkPIfhEZmMVFemP3LWppmbiYV36M4P3Of3vsYfzc3cvXEVR6ywEvA/Jc1jRDncFK2oDcdDu3Ov8N5iWo90YVnXgcQ6raGuJ9LyZKdH0pGOKpxBJuJuNP9jrvpJ/4/j70Cd0LL5h2SOa+G8wl1quBDHYihTCmley9pBBGSzGPkTSWCAZz0c+HcseesiWcTA4hVd44LskaSSxWlKI5b12WA8QiPHNly4fgfJwuKPYsbnYBh5oih3jFLqun6Onx+QTT6wPVtz1H2quB3dVWVJOAwjQyvmT6COn92Evk+XxW46JWplo07d1PadNkmGs1ybw53n2zq5U05AuzpuYW6GikzFpGOUFOUvjZTRSmvWI79LoILhD2JoABIVVyqTg/YM7VDqEnq+Zc4sVEKM63BJUxe8GIEZjK4DbtyANfydHBscmhLRGoAUbZpZPxVtEwEs+4DCd+y8n82bj7Ow+pdXQiQPT1oalCUq9t+wfmbIh4Hhsaxsg2BmWSR+8s6O8kdGF3Qh9MhXaTrPOY+EWy+Co2sCxuhFMQVVEsfdHF1iIG0bmkUs8b1h3rYoWCkt7FjGOLrZMvkLAigHkaXgzHQyITBE62EEGDTE9ehBRLNbGPLA2iPABu7Ey2WzGg4Z9ixQMbmBZeOPrtwHTP108+b13ZszG8I6XIjdJqwTZHIKgw8imvGdL/0OgECkQemPTHIlrzcbJ/b3YeItKbXB7767983oroQfk9WOogcl7Js4+nznpFLFgegtMzHKG8XynuH7GkJHgf3yBPos2V/ORMaz/tSIzX4RMFDZP7MaMQBpdpW/QfJFteVRu6VNRH LxRZLfr3 MKIZoyl9xvn274Hax5tUupIsYVDaVV5RcGMn18YV+o3s98k/FAqMnehyI1MANFlyIrta7uXS2TXfSwCVxAS6DM49OKaeR/q9qpmdgBXka6pQQMiS1Tud4HjVplGBrS/nIIzYPdsN+D+zT79Bxv4JZZQjTg1dM1lgffUomWAy5GhjPr6X3Lno632SzvocurCrWTS3QKl4U4soHqXv/2Ex2i4xULX/RvXSmkLRqIHyWehdJ+RHPK4UO23d2Mj1r5gfjPjZy8nV77PQxpj3tbgAUy0Ayc7EnqbkmOHVUvK/wLi37NK2mXGT8mSn/IiQ03Mvg20k9iMDxiPP8jDODXWsTU+My1ADrhbkgzhi6rP2YONP3Svg= 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, Sep 15, 2024 at 03:14:06PM +0200, Linus Torvalds wrote: > 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. > Removing preemption disable from gru_fault, and the rest of the driver, seems to be OK, and is probably the best way to fix this in light of the other instance that Dan found in gru_get_cpu_resources. I will submit a patch to do this.