From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (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 4A13B3563FA for ; Wed, 29 Jul 2026 03:37:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785296272; cv=none; b=K+/XiBMDXoZyx2VBPdhoz56Kv1qNAzknkYU1nE3UMLxXPfHScJHNg0qSY0RzNaM6o4AWnxciEodnSEvvToI+0Q5NVRQlGrjXlTcMuaMt+BKlEtfz5ykdzMsuRMBogB1xr5NAA6YwjnnQv2DKwd4Cte4FBMFcZ1uGs5K80SYh9hA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785296272; c=relaxed/simple; bh=slg5XGKz7gALS4qpk3IC0fOCU2hAVM2IKgASk97uvbk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=NpLVW+8KG3j3bKgs9esCFrtrNF2FCza+llEmpZFxydRIztTbW5bDH3NfXsH9Uqvw9qm6C2p2BLxXXWi9BO4OSAv/FeK40CNILONOSee/MH7ZqCXGSEFpXe+hCgY1Tf0qrhx/uJobpcP1MTR7pKFiXtUWZAnFUDANcLfRPRcbuts= 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=cdQJD1tx; arc=none smtp.client-ip=113.46.200.217 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="cdQJD1tx" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=j6sG71vk0UOw32qt1L40plvuAIirX2vWQN+w9Z12geA=; b=cdQJD1txNNKR2aB8cEiLs7bXbkbf49HyUoAL3sF8g8gCBlFDatAjuu2IR3JFkVam7BCVAfkM4 Tv/nnrmui2w9xctmaSWW9CwyPTbABmTwWBWYwJHQM8r61yG0yZalNQ3W68kyGGJ7DHAF+IlrxF/ ARvEAEyXObf1rDiV8etl7OA= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4h8yTG5sxGzcb0T; Wed, 29 Jul 2026 11:28:02 +0800 (CST) Received: from whupemo500009.china.huawei.com (unknown [7.152.184.116]) by mail.maildlp.com (Postfix) with ESMTPS id ECA1F40538; Wed, 29 Jul 2026 11:37:43 +0800 (CST) Received: from [100.103.109.247] (100.103.109.247) by whupemo500009.china.huawei.com (7.152.184.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 29 Jul 2026 11:37:42 +0800 Message-ID: Date: Wed, 29 Jul 2026 11:37:41 +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: [PATCH] mm/shmem: downgrade final i_blocks check in shmem_evict_inode() to pr_warn() To: Baolin Wang , CC: , , , References: <20260728091014.3876715-1-yujiacheng3@huawei.com> Content-Language: en-GB From: Jiacheng Yu In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To whupemo500009.china.huawei.com (7.152.184.116) On 29/07/2026 11:14, Baolin Wang wrote: > > > On 7/28/26 5:10 PM, Jiacheng Yu wrote: >> shmem_evict_inode() ends with WARN_ON(inode->i_blocks) as a final >> consistency check of shmem's block accounting.  When it fires, the >> inode-local counters die with the inode; what may linger is a small >> residue in accounting kept outside the inode, such as per-mount or >> per-user charges.  No data is lost, and no corruption follows. >> >> On kernels running with panic_on_warn=1, this accounting inconsistency >> escalates to a full machine panic, which is disproportionate to the impact. >> >> Downgrade the WARN_ON() to a pr_warn() that reports the inode together >> with its accounting counters (i_blocks, alloced, swapped, nrpages), >> keeping the inconsistency visible in the logs. >> >> The accounting bugs this check has caught over the years -- the >> swapout race described in commit 0f3c42f522dc ("tmpfs: change >> final i_blocks BUG to WARNING") and the error recovery race fixed >> in commit 267a4c76bbdb ("tmpfs: fix shmem_evict_inode() warnings >> on i_blocks") -- are real and should still be fixed; this change >> only removes the disproportionate escalation. >> >> Fixes: 0f3c42f522dc ("tmpfs: change final i_blocks BUG to WARNING") >> Signed-off-by: Jiacheng Yu >> --- >> One way to hit this race: soft_offline_in_use_page()'s fast path drops >> a clean, unmapped shmem folio via mapping_evict_folio(), where the >> xas_store() and the nrpages decrement are not atomic against a >> concurrent shmem_evict_inode(); the final shmem_recalc_inode() can >> then read the pre-decrement nrpages, compute freed = 0, and leave one >> page charged.  Same class as the races in 0f3c42f522dc and >> 267a4c76bbdb, this time in the under-count direction; reproduced on >> 7.2-rc4 with madvise(MADV_SOFT_OFFLINE) racing MAP_FIXED replacement >> of a shared-anonymous VMA. > > Shouldn't we fix the race first instead of adding more warning information? Yes, the race should be fixed, ant that needs more time and discussion. Back in 0f3c42f522dc Hugh already outlined the two candidate directions -- coherent locking between nrpages and the shmem counters, or eliminating shmem_recalc_inode() altogether. I plan to follow up with a fix attempt along those directions; > >>   mm/shmem.c | 6 +++++- >>   1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index b51f83c970bb..223484cdc8f2 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -1428,7 +1428,11 @@ static void shmem_evict_inode(struct inode *inode) >>       simple_xattrs_free(&sbinfo->xa_cache, &info->xattrs, sbinfo->max_inodes ? &freed : NULL); >>         shmem_free_inode(inode->i_sb, freed); >> -    WARN_ON(inode->i_blocks); >> +    if (inode->i_blocks) >> +        pr_warn("%s: ino=%llu i_blocks=%llu alloced=%lu swapped=%lu nrpages=%lu\n", >> +            __func__, (unsigned long long)inode->i_ino, >> +            (unsigned long long)inode->i_blocks, >> +            info->alloced, info->swapped, inode->i_mapping->nrpages); >>       clear_inode(inode); >>   #ifdef CONFIG_TMPFS_QUOTA >>       dquot_free_inode(inode); >