From nobody Fri Dec 19 07:48:45 2025 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (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 B533D225408; Thu, 5 Jun 2025 13:17:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749129427; cv=none; b=LoK4YXWoD6u5wn2WzAELHEQnmX7D4Aa9/ldqq550Qm0hlSAs4xUKMTg9Gqo/WQlQp9G/46F1KKQsOBruwT78wfKtrUspn9xTEAHRPsXuORwg/u/+iKvQvaDJhxhr5lF+UL6O+80/UGvb6nFuEZhG719k7V2a/HeEblWlWPKzqlk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749129427; c=relaxed/simple; bh=3WS954puNFuUVa+iEYJenXwqmTG2brxEMsfCKzsSfOo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ZallQL9gGtpkcovf7EANj+AGggYUzOK5HC9QHvu4i5nD/G697FweD+JbaLh6jB/9v8eMOwxueK1DZiGAcVC0v5l1q0xk8zSqeaoOiYuOoSWtsFfcrfK+S5EjIIdcuojsIzWbRg6dZx3X1jqjY5LODxcEzTbMoEQUVgMG/P6kcmk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4bClNC2b6DzKHN9f; Thu, 5 Jun 2025 21:16:59 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id B6B221A1D1D; Thu, 5 Jun 2025 21:16:57 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.101.6]) by APP1 (Coremail) with SMTP id cCh0CgDnTH3HmEFobD9lOQ--.29489S3; Thu, 05 Jun 2025 21:16:57 +0800 (CST) From: Kemeng Shi To: hughd@google.com, baolin.wang@linux.alibaba.com, willy@infradead.org, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH 1/7] mm: shmem: correctly pass alloced parameter to shmem_recalc_inode() to avoid WARN_ON() Date: Fri, 6 Jun 2025 06:10:31 +0800 Message-Id: <20250605221037.7872-2-shikemeng@huaweicloud.com> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20250605221037.7872-1-shikemeng@huaweicloud.com> References: <20250605221037.7872-1-shikemeng@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: cCh0CgDnTH3HmEFobD9lOQ--.29489S3 X-Coremail-Antispam: 1UD129KBjvdXoW7JFW8ZrWxAr1rtr1fAr1rCrg_yoWDAwc_XF 4Iy3y7Gry8WFsrZa1DZw4fXFZY9w48Wr4qqrWaqFyxAr15XF1qkr4DXrnavryxZa15KrZx Cw1xXw15Kr1agjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbDAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I6I8E6xAIw20E Y4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l87I20VAvwVAaII0Ic2I_JFv_Gryl82 xGYIkIc2x26280x7IE14v26r18M28IrcIa0xkI8VCY1x0267AKxVWUCVW8JwA2ocxC64kI II0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7 xvwVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2 z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4 xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v2 6r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY1x0262kKe7AKxV WUAVWUtwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r 4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jfAwsU UUUU= X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ Content-Type: text/plain; charset="utf-8" As noted in the comments, we need to release block usage for swap entry which was replaced with poisoned swap entry. However, no block usage is actually freed by calling shmem_recalc_inode(inode, -nr_pages, -nr_pages). Instead, call shmem_recalc_inode(inode, 0, -nr_pages) can correctly release the block usage. Fixes: 6cec2b95dadf7 ("mm/shmem: fix infinite loop when swap in shmem error= at swapoff time") Signed-off-by: Kemeng Shi --- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/shmem.c b/mm/shmem.c index 4b42419ce6b2..e27d19867e03 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2145,7 +2145,7 @@ static void shmem_set_folio_swapin_error(struct inode= *inode, pgoff_t index, * won't be 0 when inode is released and thus trigger WARN_ON(i_blocks) * in shmem_evict_inode(). */ - shmem_recalc_inode(inode, -nr_pages, -nr_pages); + shmem_recalc_inode(inode, 0, -nr_pages); swap_free_nr(swap, nr_pages); } =20 --=20 2.30.0