From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C14DC3D7D65 for ; Tue, 28 Jul 2026 19:49:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785268162; cv=none; b=AnwH0uWZROqwARN2WXyoqBy3ZG4lij1hNXBZ/DgfOUVMYJo56/wsRvZBJL1xz0Y6rPGuAnM0dUYXptBd6TE6FoUwuRBmHaDMudil/IodYDdQTkmxfrTkAFPE7iylqB7+F6EuLvGoCEX1u2QHks+3r46HxdZmcnGe63JRZQT2ZfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785268162; c=relaxed/simple; bh=qTg+vdUQo4QIA+iaG8RcPNboSADMYWvWsjxL04Uvug8=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=bIZ5aCmGwxw6Np0ExA0j78Gt4lGxEZqw2yAXckag/2kUCFdflY7/csnJ2vtXPxobjqFlQllUTGKC2DIRxwC76shjZHZ98l/h63jULDuwc86x9pxDwe1u3ltcDAxNjgy4q3zo8s69qArVqgV3YZFiNKLUcgzwPboqmB6qLnGWSCE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=RNVeSnHH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="RNVeSnHH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 082E71F000E9; Tue, 28 Jul 2026 19:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785268160; bh=peN88L+jrff3B52AQMUyFAIDeXCiNC9wXQHJpte/T4I=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=RNVeSnHHJojTv+KIuX/p8EF3Iyz3vtmgbMHduSwsht75BLzj3CUsVDXWfhJzMI4Ap L5r2B1YEKOCtJej37+j4XlLWn6ywIC0+z3ztLfwJA2Mu25eURyzcED3OVIA6IgCZwG irSjNClgZqpZiqyzI0d4Gm7SOPDIf6k5mcqdHuUw= Date: Tue, 28 Jul 2026 12:49:19 -0700 From: Andrew Morton To: Jiacheng Yu Cc: , , , , , Christian Brauner Subject: Re: [PATCH] mm/shmem: downgrade final i_blocks check in shmem_evict_inode() to pr_warn() Message-Id: <20260728124919.c023a7f9b8be446bb785ec82@linux-foundation.org> In-Reply-To: <20260728091014.3876715-1-yujiacheng3@huawei.com> References: <20260728091014.3876715-1-yujiacheng3@huawei.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 28 Jul 2026 09:10:14 +0000 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. Fair enough. Does anyone actually use panic_on_warn=1? > 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. Boy we have a lot of bugs :( > 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. This paragraph is nice - I'll move it into the permanent changelog. > --- 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); I don't think the i_ino cast is needed? blkcnt_t was possibly 32-bit a long time ago but afaict it's now unconditionally u64. > clear_inode(inode); > #ifdef CONFIG_TMPFS_QUOTA > dquot_free_inode(inode); > -- > 2.34.1