From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 403932475CE for ; Wed, 25 Feb 2026 01:58:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771984730; cv=none; b=qNnD5/KX9BtOtxJ1MurDmadFM6Q0rVnZarREHTIcv5/tDDiUXA3W5EGagEL+a85HoSwxquko9N71fhht9p5/YosYh0eQU1FuJ9JX4qx/9+ufjPnkv3mL0zyECOCGfRAIZxyjbd9B2SyHRpWITd+xREVQBZCIxj0FhH3Humi0c0Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771984730; c=relaxed/simple; bh=DTT8S3twWAsb+T1pfhMekqZyzW68uJMqUdxkaWcwxd4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=r4Yg8muRQFb9RImtczCo3rCNah0h0wIdaEyFaVrYRdj9fbsFqXSlq5N/UAk5LODq7VFeW4e/akM3NMKaDPAvY8VmSncwnoMuXzarmxL7i3/mEr611JXd2XP9Y0ikbbD7F6pEWk/RDmqLcZ55EN79PKI+tgualy3abePLQnuy5uI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=t2qO04CN; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="t2qO04CN" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=VeJ2O0BCo2zRU3gLWZ9ftz4rdNgg/fYFySx32YQqD44=; b=t2qO04CNU5gpKQcCx06GBeGbLXlyCEH2bJQDjYG/7R4my6bS3EJmloDAmRTvbccBYrjsj6Qv4 /uWld0n23lYwINN31oMWUYyt4t/HBmg3s7EwcXSsgXNcFGwXMvk0fYSBQqOkV8v/lmYnQO3zNmP xzwQ+85o/ZI5kmaXqA1SdvY= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4fLHgf6qtgzmV8C; Wed, 25 Feb 2026 09:53:50 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 8C95740562; Wed, 25 Feb 2026 09:58:38 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 25 Feb 2026 09:58:37 +0800 Message-ID: <4b219cd0-9391-4edb-83c0-b6a1c60d0790@huawei.com> Date: Wed, 25 Feb 2026 09:58:35 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: mm: Regression with v7.0-rc1 on RISC-V To: Zi Yan , Ron Economos , "David Hildenbrand (Arm)" CC: , , , , , , , , , , , , Mark Brown , , References: <1b17c38f-30d3-4bb4-a7e1-e74b19ada885@w6rz.net> <13b8d60d-1209-4650-9fa5-982381c53512@kernel.org> <1966378802.577797.1771952827516@app.mailbox.org> <78D36EC1-2596-448A-A939-0A1AC7B3D1BC@nvidia.com> <1AB3E96B-F4CA-4B00-9078-2AC20A1A60DC@nvidia.com> <272A58BA-445F-46F9-8DAB-D82E43D7771A@nvidia.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: <272A58BA-445F-46F9-8DAB-D82E43D7771A@nvidia.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To dggpemf100008.china.huawei.com (7.185.36.138) On 2026/2/25 1:29, Zi Yan wrote: > On 24 Feb 2026, at 12:17, Zi Yan wrote: ... >>>> >>>> Thinking again without my computer at hand … isn‘t the call completely optimized out without CONFIG_DEBUG_VM? >>>> >>>> >>>> >>>> At least that’s what I remember. >>> >>> Right. Without CONFIG_DEBUG_VM=y, VM_WARN_ON(!put_page_testzero(pfn_to_page(pfn))) >>> and is_check_pages_enabled(), which leads to free_page_is_bad()’s >>> “page dumped because: nonzero _refcount”, are disabled. >>> >>> It seems to me that someone else bump the page refcount between >>> VM_WARN_ON(!put_page_testzero(pfn_to_page(pfn))) and free_page_is_bad(). >>> >> >> Merging Ron’s reply from another thread[1]: >> >> “Something strange is going on. I enabled CONFIG_DEBUG_VM by itself and >> the issue went away. Let me try CONFIG_DEBUG_PAGE_REF.” >> >> Looks like something is racy, since it is reproducible reliably. >> >> [1] https://lore.kernel.org/all/30dd1efc-9bd9-4664-999e-610d181600f9@w6rz.net/ > > VM_WARN_ON() is BUILD_BUG_ON_INVALID() when CONFIG_DEBUG_VM is off. Only > the validity of the expression is checked and no code is generated. > So that put_page_testzero() becomes a NOP. Indeed... > > Hi Ron, > > Can you check if the patch below fix the issue without CONFIG_DEBUG_VM? > > diff --git a/mm/cma.c b/mm/cma.c > index 94b5da468a7d..96be62eb3713 100644 > --- a/mm/cma.c > +++ b/mm/cma.c > @@ -1020,8 +1020,11 @@ bool cma_release(struct cma *cma, const struct page *pages, > return false; > > pfn = page_to_pfn(pages); > - for (i = 0; i < count; i++, pfn++) > - VM_WARN_ON(!put_page_testzero(pfn_to_page(pfn))); > + for (i = 0; i < count; i++, pfn++) { > + int __maybe_unused ret = put_page_testzero(pfn_to_page(pfn)); > + > + VM_WARN_ON(!ret); > + } Maybe we only warn once by adding back the original check? diff --git a/mm/cma.c b/mm/cma.c index 94b5da468a7d..a73a22d34232 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -1014,14 +1014,17 @@ bool cma_release(struct cma *cma, const struct page *pages, { struct cma_memrange *cmr; unsigned long i, pfn; + int ret = 0; cmr = find_cma_memrange(cma, pages, count); if (!cmr) return false; pfn = page_to_pfn(pages); - for (i = 0; i < count; i++, pfn++) - VM_WARN_ON(!put_page_testzero(pfn_to_page(pfn))); + for (i = 0; i < count; i++, pfn++) { + ret + = put_page_testzero(pfn_to_page(pfn)); + + WARN(ret != 0, "%lu pages are still in use!\n", ret); __cma_release_frozen(cma, cmr, pages, count); > > __cma_release_frozen(cma, cmr, pages, count); > > > > Best Regards, > Yan, Zi >