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 4E5C3C83F22 for ; Wed, 16 Jul 2025 16:18:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8EA46B009D; Wed, 16 Jul 2025 12:18:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D66426B009E; Wed, 16 Jul 2025 12:18:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7BC66B00A3; Wed, 16 Jul 2025 12:18:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B54F56B009D for ; Wed, 16 Jul 2025 12:18:14 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1BEC012DCDD for ; Wed, 16 Jul 2025 16:18:14 +0000 (UTC) X-FDA: 83670634908.20.5B7667E Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) by imf30.hostedemail.com (Postfix) with ESMTP id 3C90D80002 for ; Wed, 16 Jul 2025 16:18:12 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=A9ugBz8Y; spf=pass (imf30.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.160.43 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752682692; a=rsa-sha256; cv=none; b=715qEDelOq5W2M/XQf5DIQ/MtU4n1i3uSxy4P1N9G5Y2w7s7/Fc+yprGh7Rq++eUIMNLar U8+Vylz+yzxW4OTkNhBhHfx11lbcnlhbaJrUO03Trein1McWNvGNCpJdTD0wJVW8GLbWjR jMrSFfmDmWcO0OuUAipeAJ6Gt6ZrVTk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=A9ugBz8Y; spf=pass (imf30.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.160.43 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752682692; 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=i0h7ZNJEwgMEMy/YadCkd/URI/PLHjc8vWYbdZ1HtD4=; b=PytggRFWIaBQRpfi2UVHckAxJawiwNBiHs/DBR8Z+UT0NHBxGGqhix8Ank8Zil2u4vZ7wv VCHEJQvBD4eR5B95fO8+iCw8IWVd5fi4AfrGnxaEX/juTgOXDQ5JG+8yr+rlOgfP5ptcjN qNSJmHyzVJkDujUYC6nlEoxQ3TYe93M= Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-2edec6c5511so58391fac.2 for ; Wed, 16 Jul 2025 09:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1752682691; x=1753287491; 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=i0h7ZNJEwgMEMy/YadCkd/URI/PLHjc8vWYbdZ1HtD4=; b=A9ugBz8YCLSEv4X9waFpzuaXqSx+BS59rygnmzcJqgAgFCICYoE208OF6lUQLmfALv x1xAyaZDIxaVg1WyGETN935vQO5vabiKt5KiMVLap1/QJryoYtd8pSp4quU9ekvpt93i n9u7kX3lOOnysSnuNG+Vx+NFIC2VWeKUTr4YgFS8wwc6b2ZJ2TCw/CIgozbDfB/C3TWS rnL5SiFr5FgZ64aB08NiP+WgjoMr7dzfK2sL1YjKwIgQIl7nJK83WHL8mt49XEK21aTB Kd8vikTtyfi/TX8b0gbwRh5rUHFl+9ArYQC8MFAZpcrGTHFlSj8sSA7pfRkGb8aEc5vP B+bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752682691; x=1753287491; 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=i0h7ZNJEwgMEMy/YadCkd/URI/PLHjc8vWYbdZ1HtD4=; b=wgkeDrsZO4vA/T9DUFfbS5nsUHBMMjQIFJZWuBuh+QRaMj/D3f+7zMCnFldGGlsa45 wWLR9/S+i1Y2Nn6+CCfS4b4PEg1uSMQo0biZQS87jjG/FQTjEwo8aGeVbrbAmsZkdWiI LV1dWRrFwJBp4m6ah3AawWO7vjPJ3eqsLe+wmGc7eeylYH0eA4b//BF8LE6Jqg6hVgi1 bDgtQg1/DrLouCRAbyo901PO5K1C5pAOOeL/rj+TyL6KnbX5AUsdeTlcP+UbhjvWpDNa jf7fwnUmrm0mVk93u+JHFIstEFB8Z6wZ9Nh7jPEi3/mJ3tFYviv72KZC14hxYLODdMl7 XfOQ== X-Forwarded-Encrypted: i=1; AJvYcCWBCAURCdnaV9MxC5NlwDAHGcrDsKAmNW1COASHo0p6MQRGlwTEXJtQLk96IpjElelzoOlxgWt77Q==@kvack.org X-Gm-Message-State: AOJu0YyGFu7QrRzaHG/GbpdluNqSgiEULHCX16XDBqv6MybJIKcQsisI BQGA6Fz9S9Cp9g+JMbFgW1YOcdBGKX1i395MDBoWrCCsAEV2uXpH72NeDabY+TBlMDc= X-Gm-Gg: ASbGncu3LikbkYhcUbngfPB3TdjBCAWfW+QlHVUs1gP2dtxHG8vddNNCs6nGZ6pjHqh tzzHdT2sysT3Ywn9cWYA26l41Hk7JRa5fL05ocvOcXXFGPnO97C/r44z8MQ+qxUkZOSTupBHUmq MGhK9/Yb26ZUXl9Ep/Zux824gr/Go9kTlk3A0GVWblwdItShJ3rG30c/CR2kVb7oGImJzKFSE96 cgx+vc896/O7ln0bHA9jDsIE1X87GrLSQcuLlZqraI6dS7KM2IXHf0VD0QJyOeHvet2IiCiWCOI OnorRiJw4juCWxZv3kHVyfsIyForSo5xVE6KYg6MgqcqWw+yc3AaOAut4XOngUvEieZCC8MezX/ DoyxX8maZ2UJG9DSImJ3s0UBjgivq X-Google-Smtp-Source: AGHT+IGl1nicIgvGZVPGdT72bc3/kpOv0eeNP0RRO1bv0dQrfxEDPM+s8fw+6QMoD3N3CNfgOXqDJg== X-Received: by 2002:a05:6870:ec8a:b0:2df:787a:d8f9 with SMTP id 586e51a60fabf-2ffaf53d390mr3320493fac.26.1752682690889; Wed, 16 Jul 2025 09:18:10 -0700 (PDT) Received: from localhost ([2603:8080:b800:f700:2564:68a3:7d6:cb7d]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-2ff111c4f8asm3557536fac.6.2025.07.16.09.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jul 2025 09:18:10 -0700 (PDT) Date: Wed, 16 Jul 2025 19:18:08 +0300 From: Dan Carpenter To: Zi Yan Cc: Antonio Quartulli , linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song Subject: Re: [RFC] mm/huge_memory: prevent potential NULL pointer dereference Message-ID: <27254b10-79db-43a2-a443-e7686082dfa8@suswa.mountain> References: <20250716145804.4836-1-antonio@mandelbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3C90D80002 X-Stat-Signature: iio71crguhzfopct1h8pci9pdqhm44sp X-HE-Tag: 1752682692-326996 X-HE-Meta: U2FsdGVkX1+BVX6JJkYVXifx+4DwS77le7T4RTyTipajHCRBoSWlSSxLLXP0IN2MDwDi7zNyljQaRLmQfMi6e2srHrY8GqEoW4ELhxsyVsW68hi08e012Sys+olPuBfgDa6MwOab4UpSdbbZa6b/fe27i/UmUn2ouCKM45xOFXRk1c1EVeR+EZQsfJbBqxQBt5XFfafqXwydtzMdn8Vj0LzlNqzsJIXmKEzYHLFlR8V6mFNF2mkR5B+KjFs04GNnQR6YtSoozSPO4f/u/vXEZX3Y5Go5Qz4EokRsaT5e5ktbPMUc+2pVL2HXs2Pq3wNw4j/+yVgzjzkKlhFRnUo61kvIQb8ByFUSMshzY9zmj+BdkgTAXof5oAbtcq7ftnW7HI3+LvdGT4+tpO3rKjMMOfVAXSZfEFuaj+PBqouJ1e8UrFuj7Q2kSGHO20TF+ctTeGTrLvXprijUk5+9CmZCPYKZ1d1YuCQtL20cF+/KOKqyiK0VLJRHwOw3AT5rG7+uZ7fBxViVB5t4Sx2tlqu1mFacu3zlVQo2LDDF8gReG4KevzTSSayuddF238/pfky8Zq6tcYRMTFJyMagQKtMeBiQOxJim9fLxo8eykGD0y+D9pv1NTNBQofDz7sWOWwSsOYGBw/6VElHtqUBQeNSGLVAptcX4VD710Ue3lZtV3TGFP6tkSziYwxFC4NUhfFOheN6b+V0X8PKePRzum+q6B5zvbu5GdtW6XdRh4QRMnCYKogP3crk2lB/nfHUOFqroYvWqjs4MTE8J3PRxGRcXdziIafnoN2oy2YR5hkQqpuEgAO4v6CA9YSv2UzVz3updYCsZE29218Re2QhKhzfQsecM2Shi2PcJS1dO5rTUa0UaVvIfc0miJfSDY59sARAVrHb1MT6ILVDrjiQe7mIGvOlW3NhFNpcOktTWvGu333Sot6LT74ZakOkVGja6dnfE5qPVRvDUOlxTk0J844j uk2gAs2h jePqTbTg0TdHZe8TiavnIbEa/adG77VrkHV95ERn8XBKSuPW6FBd2QZa50wJcTbZWvPjrYdzG/K7Tkwf9ZvcrRwr7M0j11gSPmdt2Ek8sQX9a6WU3jKpXwkceExCmEQSYYJS9EehHzFwJE0cJJdb4JdjgAT89JbQGcIU9yEc7LMQPZGaN3iHcaWYipxeEy2DkKBlZVifcuVgi8JupMehmjCmRfBP74L7j/MAUfbU94JglfLpDZvGuuS0OOr0OFHE3l19K9afeJK7YqpweCNsQQ9j0R5x9EHeWCOSYfucPZmlqS71qkzjZUjC06tIGxPW1snXC4mFp3U0UH4Cirpo44KAGvrzRlvQCYgaSyJIirVxPQBu8sLP7n/Xf1Yzo+1DPYQTHTv5meCzHE8Hb/qMq17UVSm3qhHJi48MR5hGzxKFa3x4BkU8UIS31rf7Mszv+JdkHAMgmm+JhIcRulZhmxswRUSK3+HJst2NDDFjLb5bt/i527NVDK/768ch7+Qsh0Z5U 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 Wed, Jul 16, 2025 at 11:10:00AM -0400, Zi Yan wrote: > On 16 Jul 2025, at 10:58, Antonio Quartulli wrote: > > > I just found this issue in the last linux-next Coverity report and it > > caught my attention. > > I am not familiar with this code, therefore I am sending this patch > > as RFC because I am not 100% sure whether this is a false positive or > > not. > > However, it seems potentially legit to me: > > > > In __folio_split(), when looping over folios we dereference > > `mapping` before ensuring it is non-NULL. > > > > Following code in the loop body performs such check, thus > > suggesting that `mapping` may be NULL and accessing it > > without any check may be dangerous. > > > > Add NULL check before passing it to shmem_mapping(). > > > > Cc: Zi Yan > > Fixes: 00527733d0dc ("mm/huge_memory: add two new (not yet used) functions for folio_split()") > > Addresses-Coverity-ID: 1647614 ("FORWARD_NULL") > > Signed-off-by: Antonio Quartulli > > --- > > mm/huge_memory.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 389620c65a5f..d649026db95a 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -3802,7 +3802,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order, > > > > /* Some pages can be beyond EOF: drop them from cache */ > > if (new_folio->index >= end) { > > - if (shmem_mapping(mapping)) > > + if (mapping && shmem_mapping(mapping)) > > nr_shmem_dropped += folio_nr_pages(new_folio); > > else if (folio_test_clear_dirty(new_folio)) > > folio_account_cleaned( > Hi Antonio, > > Is there a way of preventing Coverity/sparse from checking certain code? > This non-NULL mapping issue pops up every time I touch the code. > > Dan Carpenter reported the issue yesterday and I explained it is no issue[1]. > The same report showed up when I added __split_unmapped_folio() > back in February[2] > > [1] https://lore.kernel.org/oe-kbuild/64b54034-f311-4e7d-b935-c16775dbb642@suswa.mountain/ > [2] https://lore.kernel.org/linux-mm/2afe3d59-aca5-40f7-82a3-a6d976fb0f4f@stanley.mountain/ > > I wonder how many times I need to explain this, although I appreciate > your effort to improve kernel. The way to disable static analysis is to wrap the line or function in #ifndef __CHECKER__. This is a bad option. We could probably count how many places do this using one set of fingers and toes. We don't like defines in .c files. I hate when static analysis makes the code messier and worse. We always say to fix the checker and leave the code alone. We generally try to only report warnings once, but in this case you changed the name of the function so it shows up as new. All the scripts say if you change the name of the file or the function that's a new warning. When I'm searching for duplicate reports on lore, I use the name of the function as well. Plus, I looked at the surrounding code and everything on my screen was from Jul 7 so I assumed it was new. The best option is to add a comment to the code. The next best option is to just endure the occasional false positive. One idea might be to add a hash tag to static checker warnings/patches so we can manually search lore.kernel.org for the filename and hash tag before sending new bug reports/fixes. regards, dan carpenter