From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (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 0726A291C10 for ; Wed, 29 Jul 2026 03:14:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785294875; cv=none; b=fa8bfKPHXN8l1XAtJeZsP5y448x9UiGG1i8MsA65c/rVeiG/36hrBPF/ia5BXzyl3n9od1WErtt45Et9UmHcwe6RzZDwu7+J1CzXMcS7vHPcm5/DP/+QoCpTFGIOHY+PY15aLiJM4yzM+PARl/5IK9gtry643j4fk+c9mYhM4so= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785294875; c=relaxed/simple; bh=KcV65BUwwMkjDVh/m7d3HQJX7PowOnhlVecf2yNthS8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WvLA97Dq8n/o71Q0wS8BWCtVYKVvGvpb+0KSEfafptmRFjWtoM4oF0nUCxzi092EAajGnOxoEsDG01tY5CWe86orLjYbwVQ4qBr/tGpfhIqRBtiM4ipSwAGwVldn5+8ZyKFTycgzaB51nxZl62dSd8yajtHgB8WqTROMhZGU7RE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=ay19z7vu; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="ay19z7vu" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1785294861; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6Js29cMIe6dBfjgvYRjFeMp8XtWwBRJ6PJfzpQUpjy4=; b=ay19z7vuZJnfejF9Z2QmyBbsQBBeAODrjNj26ErcOZqWoK1nVMlI73DGGo6QleLhtg6/CDw9PCBxUntpRYforASiB1M1BWW+m8Q+j9GT6rUUSOA/n5NmKuCJyVluU2BadCb39DGh1dN44d2bIUab4oAw8a+5ozfXLunYP8KEG+w= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X80kkiM_1785294860; Received: from 30.74.144.130(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X80kkiM_1785294860 cluster:ay36) by smtp.aliyun-inc.com; Wed, 29 Jul 2026 11:14:21 +0800 Message-ID: Date: Wed, 29 Jul 2026 11:14:20 +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: Jiacheng Yu , hughd@google.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, liuyongqiang13@huawei.com References: <20260728091014.3876715-1-yujiacheng3@huawei.com> From: Baolin Wang In-Reply-To: <20260728091014.3876715-1-yujiacheng3@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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? > 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);