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 007C5C677C4 for ; Wed, 11 Jun 2025 09:11:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6833E6B0088; Wed, 11 Jun 2025 05:11:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60DC86B0089; Wed, 11 Jun 2025 05:11:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D5476B008A; Wed, 11 Jun 2025 05:11:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2BAE86B0088 for ; Wed, 11 Jun 2025 05:11:35 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9EB1E1204DB for ; Wed, 11 Jun 2025 09:11:34 +0000 (UTC) X-FDA: 83542551708.15.B3AFCBC Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf19.hostedemail.com (Postfix) with ESMTP id 51ECF1A0004 for ; Wed, 11 Jun 2025 09:11:29 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749633092; a=rsa-sha256; cv=none; b=0E4fVAUFHq5OeSg2ZqlM84479S1io/Y03ZMGF6AJTzxR2CpN9JZ5OKGh1l8yF/FAjgOs83 XT+8pxvkv3im8W0QTBLnhdIj9lA7jm4lGPpfZ5301cnaj/2b6mp/ChKH1A2C6aw8unbHi0 Qu4nQnzlhdltcTOsgFkFY9N+40ylvAk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749633092; 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=rUBOuY/27MjrZtGgQ1KtY/P+swCBphWMNqrrlrFS6cM=; b=KOi1oD8LnzUCdSW8RgEpNcHRkMr63pLvNdyeLZ3a2uRnN8fMIi45J5baD8LCTq9kCTs9bV S7Qv22f+7YgbuLKQwgO0RRc+LFOMwDSnwiOmR0VEimgwVZ1VSMfBQp0xORyO0LyWyxLAvn Uk+xBzfOLWaOHcghavPVEqZn+wijzqQ= Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4bHKf74G8CzYQvr9 for ; Wed, 11 Jun 2025 17:11:27 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 9273D1A0F86 for ; Wed, 11 Jun 2025 17:11:26 +0800 (CST) Received: from [10.174.99.169] (unknown [10.174.99.169]) by APP4 (Coremail) with SMTP id gCh0CgAniFw7SEloD7+1PA--.34437S2; Wed, 11 Jun 2025 17:11:24 +0800 (CST) Subject: Re: [PATCH 2/7] mm: shmem: avoid setting error on splited entries in shmem_set_folio_swapin_error() 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-3-shikemeng@huaweicloud.com> <100d50f3-95df-86a3-7965-357d72390193@huaweicloud.com> <24580f79-c104-41aa-bbdb-e1ce120c28a0@linux.alibaba.com> From: Kemeng Shi Message-ID: <93336040-f457-d8a1-29df-f737efa8261c@huaweicloud.com> Date: Wed, 11 Jun 2025 17:11:12 +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: <24580f79-c104-41aa-bbdb-e1ce120c28a0@linux.alibaba.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CM-TRANSID:gCh0CgAniFw7SEloD7+1PA--.34437S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tF1UArW5uF17Jw17Ar4DCFg_yoW8KryfpF WUK3Z5KF4kJrWIkr1ktw18tryY934rWr1Uta93Cr43A3ZFqrn8KryrWr1Uua47AryDGr10 qF12qas7Xas0vaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21lc7CjxVAaw2AF wI0_JF0_Jw1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1D MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUwx hLUUUUU X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ X-Rspamd-Server: rspam01 X-Stat-Signature: 81pqtf946acy5rnjzgdfx697ihfdne8e X-Rspamd-Queue-Id: 51ECF1A0004 X-Rspam-User: X-HE-Tag: 1749633089-960574 X-HE-Meta: U2FsdGVkX1+Y3C+VvUBUrtBubq7tshWM9RQySZ2M9cr1yVOvAyNtpsFA24qbL9h293Nlt4jlPvFU+zvX6otQ+RYPKmu6fwqQyTwB+0r8Lvy/Tn+rUl9qY0EWpaO1SWoPefrT7uTCAx6f9jEAfjCpjYjB302+ccfg6I7PmD/CwWA5qT6kJ2fc11jdS6sJR5QyAJnhH2QfESD047/v+RAu25d8xOsTGAXoLvCMcoRii+g8+Q+dxqrzj24M1Ccj2/HPpiv6xmRXTP8vjvBXz8u0ugbnC4vBeUk7b1t+M0IlFHLfoj5xfYPOEtORSCnfPoxi9Ix1WqrViioOoepluxI+J92gW8Ia/F+sxQphs5vQGzyqGTNfZBtjrmt7hPGCVYGiYDABHyfQSjrl2Js5vnrr/dRgu2aHjNNpLfJvQGShNZzRVYSUe21A5CQcOWrwdHClGeCDqgA6uSRB0AGRLgHvdM/e/NWcLBfFswytI/lnt22nvAC6OWNcRMUOO41vKi00ZX0Sljw4LCrMUmoCN3vjiQ1eQsE6PNtpO8UwDlJJyMPrCZzB88kpo+TOgPNMv0x8esf9Nd2v2lDMglJS8Sn1KGMCTvW4Wj42tVzC+/lOmwh0MCweoFFotrkKP2d4DEODDozc5RKEDB+BPkz7SHmFaEPcAuLmTey1ffGNIKvFZ7SXtP1OXhXHNSMmq2vJ8UGZqtG+5cTl9RpHYe/FX2WsYGIFH3YRWM7zaaSOPZihnPRZOTuGBk6myJD3/VrG3zzgXGYWKBFUFMxvrC+eCwsnHSH7URIDPCLFRsTgtfg9DhtmaceDAcswb+P3BoKQHpknrIOnGjrGximxYiiJcITN54KEudOd66jS7XlOrnj7fXw2tbeWlxIy49ZSdRqqCKNjK7jlCmzzoO4vUNGnh69m28gS41+wK16LXRqhlAjtSXdL/vPF2lpS52rO1QNN0y8CahPG/9xC6d58UYBM85P /9TMIZ6v FPKSVnrY9oJj3YmhQVHoJT/4dxk4gR+PYVJnZjHtSnHKu3NZiykULKfNLMp8xFl8Rke/+kE/aJiZWTZg5Ys8Y6AVif/0BVRcOz94fF2i4QqTCPI1J6lnI1LrV5kIamE9pDpuVb2UMj5du9PwRGPcCdnmNyHGNclAO6fec1bwWnb/f9sZXc9AsKRfjnFyFYwC6+0kZWCBT6U7x3QTVN+NArIiyoQ== 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:41 PM, Baolin Wang wrote: > > > On 2025/6/9 09:19, Kemeng Shi wrote: >> >> >> on 6/7/2025 2:20 PM, Baolin Wang wrote: >>> >>> >>> On 2025/6/6 06:10, Kemeng Shi wrote: >>>> When large entry is splited, the first entry splited from large entry >>>> retains the same entry value and index as original large entry but it's >>>> order is reduced. In shmem_set_folio_swapin_error(), if large entry is >>>> splited before xa_cmpxchg_irq(), we may replace the first splited entry >>>> with error entry while using the size of original large entry for release >>>> operations. This could lead to a WARN_ON(i_blocks) due to incorrect >>>> nr_pages used by shmem_recalc_inode() and could lead to used after free >>>> due to incorrect nr_pages used by swap_free_nr(). >>> >>> I wonder if you have actually triggered this issue? When a large swap entry is split, it means the folio is already at order 0, so why would the size of the original large entry be used for release operations? Or is there another race condition? >> All issues are found during review the code of shmem as I menthioned in >> cover letter. >> The folio could be allocated from shmem_swap_alloc_folio() and the folio >> order will keep unchange when swap entry is split. > > Sorry, I did not get your point. If a large swap entry is split, we must ensure that the corresponding folio is order 0. > > However, I missed one potential case which was recently fixed by Kairui[1]. > > [1] https://lore.kernel.org/all/20250610181645.45922-1-ryncsn@gmail.com/ > Here is a possible code routine which I think could trigger the issue: shmem_swapin_folio shmem_swapin_folio folio = swap_cache_get_folio() order = xa_get_order(&mapping->i_pages, index); if (!folio) ... /* suppose large folio allocation is failed, we will try to split large entry */ folio = shmem_swap_alloc_folio(..., order, ...) folio = swap_cache_get_folio() order = xa_get_order(&mapping->i_pages, index); if (!folio) ... /* suppose large folio allocation is successful this time */ folio = shmem_swap_alloc_folio(..., order, ...) ... /* suppose IO of large folio is failed, will set swapin error later */ if (!folio_test_uptodate(folio)) { error = -EIO; goto failed: } ... shmem_split_large_entry() ... shmem_set_folio_swapin_error(..., folio, ...)