From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD5CCC61CE7 for ; Wed, 11 Jun 2025 08:38:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50EDC6B0096; Wed, 11 Jun 2025 04:38:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E6E96B0098; Wed, 11 Jun 2025 04:38:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 423866B0099; Wed, 11 Jun 2025 04:38:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 247676B0096 for ; Wed, 11 Jun 2025 04:38:35 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D09531404B4 for ; Wed, 11 Jun 2025 08:38:34 +0000 (UTC) X-FDA: 83542468548.21.77CEBEB Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf08.hostedemail.com (Postfix) with ESMTP id CEC97160015 for ; Wed, 11 Jun 2025 08:38:31 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749631112; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oe/iXEFWAWBubGbwCQqF4S1fnIzRGP1U6ZbJBnpDQ2Q=; b=F9mw/tC58XkvIRXF0FKn2J5HdF3pHU0U8rCCmrnkjLIISnEQzKobayH7jpelFLpczsEhJd GoRYZiE/64KFYZDP540xEb+nrI19W5kbPj63TUQ5sn+/bq0UpFJKLLXGySOLkihaLajGvA fDs72sSg9Qlp36F5rehGoIzOEqTgIko= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749631112; a=rsa-sha256; cv=none; b=3EBEQX3KZWKcTe2YVPBPFvh/DvXvdMw7SwcfCMrlcNHYh+fXBXWFf/kjKZfQUVFNfkznS2 RjuWtit7J2qzVsGxbpeKGk3JwrHD0SrF3zHpSdoqUN6/GuNPVysWd3v+zEOFr2/5ysCm4n DwN5aqWJLfAKmHVfsevtU0nha2MM3zU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com; dmarc=none Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4bHJw56vqBzKHNK8 for ; Wed, 11 Jun 2025 16:38:29 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 4DFFC1A0844 for ; Wed, 11 Jun 2025 16:38:28 +0800 (CST) Received: from [10.174.99.169] (unknown [10.174.99.169]) by APP2 (Coremail) with SMTP id Syh0CgCXoGOCQEloTNk1PA--.4547S2; Wed, 11 Jun 2025 16:38:28 +0800 (CST) Subject: Re: [PATCH 1/7] mm: shmem: correctly pass alloced parameter to shmem_recalc_inode() to avoid WARN_ON() To: Baolin Wang , hughd@google.com, willy@infradead.org, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20250605221037.7872-1-shikemeng@huaweicloud.com> <20250605221037.7872-2-shikemeng@huaweicloud.com> <3d07c68f-da11-43d8-a2da-6b200b2fa40a@linux.alibaba.com> <994283d9-2dc4-6887-5d46-247b834879b5@huaweicloud.com> <9e59f1f0-db3b-2182-4485-887ac7036bfd@huaweicloud.com> From: Kemeng Shi Message-ID: <1ded199d-149f-d64c-536d-21ce158a09d6@huaweicloud.com> Date: Wed, 11 Jun 2025 16:38:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:Syh0CgCXoGOCQEloTNk1PA--.4547S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWryfuFyxur1xtryxZw4fXwb_yoW5try5pr W8Gas0yFZ8Jry0yFn2qF18Z3yaq3yrJa1UXrW5CFyxCan0qr1SgrWUKrWj9ryUCrWkGw4j qF47K3srZryUZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21lc7CjxVAaw2AF wI0_JF0_Jw1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1D MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUFB T5DUUUU X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ X-Rspam-User: X-Rspamd-Queue-Id: CEC97160015 X-Stat-Signature: rsiwa9jjkjiyrjbh3onrjdgdfcr78nfp X-Rspamd-Server: rspam04 X-HE-Tag: 1749631111-451379 X-HE-Meta: U2FsdGVkX1+2Yqvqi0IkV+QdLXTIjJ/mUxOkyBq/2OFd/oRpdt7Ng4X6CZfAqusC+ZaO3icGIFgIQ/WUuwKxgvZuNfeoDurWUrC+GEHSkrceoGR/GbbWCWtBkC7ls/XD2LzjrnGzQUDRbMguhqlKx83/zl0iidN5UOD6HdiynrxIJQx+aE+8Jn1VcUZXf10Kgng1Q/RhiYgDVIggXPXcOlU9F02UUnFVKdPpmpU+6TuytPpI8Svf1gTV9O1ak2+a+1PMNi9nrYxujADEU1Wa96LHmmfGr29poO/FzGhu6m51w5vl2qTGd1mRa2EMCyVW8FfvZ2ovPdxDMjOXTZhZKiSQgOJYUQGx1UB0YRJS0tv1tBbrEVSg0xCeopsPo4jzu0jlEzk2Eu85u6E2XsOUZV4MrdPgMsiwD1Nq1R+bo7OyWl/TS21RjC+DwpS7it261G8FKNTN9JzqYHMSBF9Wcdg4pZ2LpKl8dAmT4+B6WnqpbjGTst+HNoM2yvpuq1CxIkNxXatz2F1ltXBipw0iEF0EFfqCf35ADgguZCEQ0Rr9Kt9oZqRF1p9/YXOya+AQ4g2xmPfSZMZEk/UGbx2ugG39iKo4V+4tBYETD6W422gadRm9DAnDl4wUJVkQJkVUsvHrpuw1aBUjL/j1D/YBbbUGqR4K1SZVMBfctOcyeZwuFTfuaNJTuC9Q0F6WFU88wvU+CUrljRvGWB6/D5ftrizyuAa1YjHwC3ysmIORTpaCAcniIECbabqEsCYwyBxDB0JBhpcGyJvUN1iT/MhFEQutugwp+aLezbwyJLPSz4BwhO0DUNlm3rlVEydnCW5Js8EhJ2YzsgAK+mKP7S6xNQ7BVuHazORdINfTH36ZBHuarQCs/tpD+rgP3uWQtBBxMLoBGB4HXdam7CGycA7Tqot1Y62tKLopP3HwL0OIvcqbRkcMUYrdEiSmfQ+VJIrGcAdZXTJ5/eXxPaeLIwr TM8GONwQ CyLCKTGHgNDKNfzJIkhnRkSCITDbQSNEOIPH3CB0F3RCm+n4Emki+/JSJ7WlVXKfIHHIwHgDj2F7pIG4PW/3Q+MD80XNjcn/g6dvJ0ofKWiSzNK8E1FPeQHZ5MrA91nru28Ixbadu7dUYqIDwMbi4aIqZOea4evGAC8jJuAZfsvp832ollUTs7V3HjV8Pz0fbcE26/gSAMUNYA7GkQHGvb2jNmA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: on 6/11/2025 3:29 PM, Baolin Wang wrote: > > > On 2025/6/10 09:02, Kemeng Shi wrote: >> >> >> on 6/9/2025 8:46 AM, Kemeng Shi wrote: >>> >>> >>> on 6/7/2025 2:11 PM, Baolin Wang wrote: >>>> >>>> >>>> On 2025/6/6 06:10, Kemeng Shi wrote: >>>>> 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); >>>>>    } >>>> >>>> Have you tested your patch? When I inject an error to test your patch, the following issue will be triggered:As all issues are hard to trigger, I only run some simple test to ensure normal >>> process is fine. Could you share how to inject the error to trigger following >>> issue. I will have a deep look. Thanks >> Sorry that the message is truncated. I mean I only test normal process is fine. > > Please also test the swapin error case you try to fix. Obviously your current patch is incorrect. > >> Besides, I think there is another long-standing issue which could trigger the >> following issue. Here is the issue which is possible to blame: >> When swap entry is replaced with error entry in shmem_set_folio_swapin_error(), >> we will reduce info->swapped. Afterwards, error entry could be deleted in >> shmem_undo_range() and the info->swapped is reduced again. As a result, we >> reduce info->swapped twice for a single swap entry. > > OK. So you should do something like in shmem_find_swap_entries() to avoid decreasing info->swapped again. > > entry = radix_to_swp_entry(folio); > /* > * swapin error entries can be found in the mapping. But they're > * deliberately ignored here as we've done everything we can do. > */ > if (swp_type(entry) != type) >     continue; > >> A simple way to confirm this is injecting error to original code. Could you >> share how to trigger the issue or could you do the same test to original code? > > Yes, original code is good. I still suspect that it's another long-standing issue which is triggerd by this by accident. > > A simple test procedure is to allocate some shmem memory and swap them out, then swap in the shmem while injecting an error to trigger the swap-in error case, and finally unmap the program. > Sure, will fix the mentiond long-standing issue first and try to run this test. I will appreciate if you can share your test code if it's convenient. Thanks