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 7E4A5C35FE7 for ; Sun, 15 Sep 2024 12:05:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D86D66B007B; Sun, 15 Sep 2024 08:05:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D351D6B0082; Sun, 15 Sep 2024 08:05:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFC586B0083; Sun, 15 Sep 2024 08:05:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9C6F86B007B for ; Sun, 15 Sep 2024 08:05:46 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 243E9AB3F1 for ; Sun, 15 Sep 2024 12:05:46 +0000 (UTC) X-FDA: 82566843492.24.DE55652 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf03.hostedemail.com (Postfix) with ESMTP id 3AA522001C for ; Sun, 15 Sep 2024 12:05:43 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=fBT6yDoG; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf03.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.221.53 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726401824; 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=D3ltNTh53H2BArDmVC3hSkV6g+P0oJAsjknn+YBRiF4=; b=ki8pfEPG326KDVmVJsF6VOLLs9zmjgkeIKp9+ZUzS6fZo5YLXLcCqJe1hm3ChNYX2pPdTC 9N5ce7CaTz9rm6QswJtu2H+s9WwDsbCn45zWn2fuklaq2qqwP9zU54AMSZ1DtnZ9xUplYk wBaD0B3zNS919pdnAGiL7su5L117wNU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726401824; a=rsa-sha256; cv=none; b=bOVro6Bvs0mlW8DHB3O2m/AWtV1JgzdhZbQ+Qg5pFURIXgYBygSwnBxrwy5A+1Ouizjpfb eSbd+3trLoYGxeqvKU86L6BW6VdgJpR5TZae0MgdavH/DKpMYNy4Rhg77VHy50lPR6U00g VME9eAvnbqezE0zHdMOnx3G33dempLk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=fBT6yDoG; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf03.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.221.53 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-374bd059b12so1440370f8f.1 for ; Sun, 15 Sep 2024 05:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1726401943; x=1727006743; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=D3ltNTh53H2BArDmVC3hSkV6g+P0oJAsjknn+YBRiF4=; b=fBT6yDoGHebrAwmJGlYgaU4pAHMtaiPtfYLDYy6xbXcIrdP6wkUpXhQZYH0cLFjxuQ Y6Q5+JwLhSdTipf3rUYCKAd7eHrSY5CQ7Gf7J/Se0hW/YjMHl0pP/QwwE6ttgTQ7J9fm CgAjzmSse4l8a3svUvjF0eOmM/w6tx3HvaRaCTP5gFh2NtlX5N5/w6ueQKHg6lplh0/c H/HOCgwupEZDXHu0YEd9Klrjf7sXIY3FSm4k7AhPRdfiRP5KlcsYTf2ipWnj4MJbvqga ImjNr4a5ROXnHbcH8b3Lj20SqQoG2S92FaxzluqFjOMBotOyjjc7cbjh1KGDHDHsXY1m xY3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726401943; x=1727006743; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=D3ltNTh53H2BArDmVC3hSkV6g+P0oJAsjknn+YBRiF4=; b=p2lWiu1AdQSel6IUwbiwth73AIZeFBgADq2RTF7nkx+9Ww6Kxl0Tgi9eGZ+LGm3CX8 hOZW//AGCsuXE/lDsMTnd6tEKZNbQupfTlS1nsOcJQ2doJFmgimp+kdrZvrfzlLx7fdx lI45itUghHmlTQAhOhuVW5bw9gqdOnjTEdLzyCZwDfplcadQwLhALaZKLDnRibm1Y/DA b9gTCekzYa4kSfeNbSwCZbQv6D71XoiuLa1IBI09tXci9jbpTkIyqvpQjd1k83j0knf8 iWBqgqh7W3ZNURp3C0XtYjI4X5dL4PHAVOprO+rxBNpc8AiHuWgeiT5hGPBQnGqVjQ5w 3lAA== X-Gm-Message-State: AOJu0Yx5oeixyCb91Bzn91jG+JM2jkVfyBxuFoUTeRtm4SRDGD6QrRYP uyo65F2Q6sr3tQ50zWiaeXoWj8foR3EGX+a5kI4TBJsK9Nab81bO7eJda6bIASF6zTJA8YeZFuv + X-Google-Smtp-Source: AGHT+IGwVwm596aBbaK36vG4Ua0SlaCa/LeGFhyuWwEBxWpEadRuZxuG2IbQNWV3nX8nNx1vb5vQcA== X-Received: by 2002:a5d:5642:0:b0:374:fa0a:773c with SMTP id ffacd0b85a97d-378d623bb1amr4357426f8f.47.1726401942696; Sun, 15 Sep 2024 05:05:42 -0700 (PDT) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42da242147esm47318275e9.29.2024.09.15.05.05.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Sep 2024 05:05:42 -0700 (PDT) Date: Sun, 15 Sep 2024 15:05:38 +0300 From: Dan Carpenter To: Linus Torvalds Cc: linux-mm@kvack.org Subject: Re: [bug report] mm: avoid leaving partial pfn mappings around in error case Message-ID: <58a7aebb-6ffe-4909-a7cd-d98063509a57@stanley.mountain> References: <8e3ffaf2-358f-479c-8de6-46e1b0bb0c5f@stanley.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3AA522001C X-Stat-Signature: fbn8gsadcn9yzap6hcpbhgcf3c81c4kn X-Rspam-User: X-HE-Tag: 1726401943-387327 X-HE-Meta: U2FsdGVkX19jtxyIDFh5rbPokoq1KpSyd6POj1cD055NpjfAcSDpiugqq3Y3JhttbOQo1GkFxHy6xCqX9xTBopfFoaBpUAh+xkMYqI+rQzwEwhCt4WvQBPesNQnWhhzaLQuDTKI+iPcyOppmM3h02Aq8v1FLmk236u+fWrNvTHZRGychpli4IITY9KKKvz7DM2G8kui+o0BRzv6X7m3Q9bB4Ng+IRovZzC3KO0oV0lr2Na2DweMDtp4GkjBZmbbGI9TlnQKANRH4qvhz2hV44IwXtNR82Vjok1Sh0aHtVjjYbYZE/r62s2KClcKGnzbCmndS94/VKSbqxkxtsd855VJHu8ymiP5NmyDq//AnEhnc2eSJgV2mPk+htqod3PFM24BsCNprmDymINFXVVj4cuQ13kh5pnUsPsONwM7y0olveGt/8n53bYYJmm6HjmdN/KSb+fopZu9aM6FSuUGe3KLPxCB0qCo3eSaTrCspubyzLDIoDaNE6Tb7VEze0rfK+sC4F5KP4H3d9BAzsAdgMeo6lxLKsI/rzISSeAjV+gRGc3krOCS25vK3CfVMAhM68jwp83WHV59EC/iP7s8ImECWX0IR/LcBbrt+YLD/nMIZvHylg6uJk0PaXS2f52pXBjUukBDbdAlTAoGqhjSvDud9796VivSOHfS1Up7vcV9Z8a42gRXHPe9j1kmjVQrDLxzeQnzd47NeAPbypaKE4corcyuuNCHoS3KFjzaWLl8rNJvSfuczGC5j2mWJiYmHz3CQ2qi/pkzYN8YWYedr/B5jLxCIz/0u3iQmSSl4V/S42/M8O2sD5BZLyg0zHAcq1pqHLQ36NalZMTLjPUfRQAYzEODHTd3vSTarrhdFAY0/UmbB3E0QmwHq8F2vNNBY/TNiaQvVWic8sAN3R4bS24Zly2mxHv4o05F1bi1vZPCVBUZtvGGvlXQ/WitmQGvGCq0Pux86raKLElqXRXM DSQI36Hw dQsPhXUjG45L5w350PAyHlZeHtp8CZkehVhUv10zK4EZzjonOMO+J+5HJ7OHfnXU9z7RSwA4mv8aNAs3KNJoiu4jRNWBWRa1j2t1tuam3j4aMP4pnoV7GNs2AQdwuugJOyGRs4cha86V0aZ9ZLlVwEEigS6FO5MXdIZv5qkIx+zjctXv+it3++1RGzdb82JLmheOIN5QCDuSDRkb921fV/zgWPdXuE7mfmwwDdwJFiFoN5OOGHVc/7hpPAhwKBKrnlYRaEP18f8ONYfRx57h9Gc9w7zY02AmPusx+usL8uBFkJZM= 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 12:23:31PM +0200, Linus Torvalds wrote: > On Sun, 15 Sept 2024 at 12:08, Dan Carpenter wrote: > > > > The lru_add_drain() function at the start of zap_page_range_single() takes a > > mutex. > > Yes, that shouldn't be problematic. But: > > > It's the preempt_disable() in gru_fault() which is the issue. The call tree > > is: > > > > gru_fault() <- disables preempt > > -> remap_pfn_range() > > -> remap_pfn_range_notrack() > > That code is very odd. It was invalid to call remap_pfn_range() with > preemption disabled even before, because it will allocate the page > tables that it fills in. > > But presumably *that* never happened in practice, and so nobody > noticed how broken that code was before. > > Now smatch seems to see a new problem, but I *think* it's because > smatch didn't notice the sleeping by p4d_alloc() / pud_alloc() / > pmd_alloc() because those allocations are all conditional (so smatch > doesn't see them as static violations). > > Put another way: I do not believe this is a new issue, but perhaps a > "new to smatch" issue? > 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. regards, dan carpenter