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 753E6D42BA2 for ; Tue, 12 Nov 2024 15:49:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF8856B009D; Tue, 12 Nov 2024 10:48:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA66E6B00A1; Tue, 12 Nov 2024 10:48:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9206C6B0101; Tue, 12 Nov 2024 10:48:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6FF526B009D for ; Tue, 12 Nov 2024 10:48:59 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 25F2F160299 for ; Tue, 12 Nov 2024 15:48:59 +0000 (UTC) X-FDA: 82777875978.14.B5D6308 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id D8BEC40006 for ; Tue, 12 Nov 2024 15:48:37 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="HjnTyT0/"; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731426482; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aTK0cEepUZLimABo8nAccUNxBY1Jvh+KAU/SAPsoyn8=; b=wE3BqPFF/xLikExjDLRfUnuF9aXG5OSKg+2Aq34b2KyYvzFP2+tmgl4ENOtGijMWCLNCFK L6x5pDYGCMOoOMUJ5pVYueRXcJYNuyjhIHJsOhrG6faG8MS9K+tlNERenfHtCelInE/r/W KUAQcMzuroC0zOTqnSwlmsPA3ZIcvBs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731426482; a=rsa-sha256; cv=none; b=S2mQy39ldaLI0I5auJ1t7tvkkvrfIkcFW2MImohKF0/EABKpj2e99nohHvFaarh7WG6iOq 8cA+IAFJRPs/BLLqzXTPtJYXLMy+jUz8l82cz9wpsoF8VQ6UHuafdzKWlxEiTukRwKHuEk nkUYBLcGpSYkJ1aa+uEmZmv8Q2RbpRY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="HjnTyT0/"; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aTK0cEepUZLimABo8nAccUNxBY1Jvh+KAU/SAPsoyn8=; b=HjnTyT0/IV9s5rkgOlqxXQ0fZE lJb2Nl5Ce1w9kI3ysQsAqA8pyltZzpggSahQ/CDYno1CO/HhL0pZNvoZDFNP9PzDIz2Pp2fBEniKv lVSARYlCXWOxWwSxWhQpLbBp3fIjLv6rAGK6FnR/tw9wcHhQiD4iSeCraSiXAJ/iVLihhGoUQu0sy P8ML6Vkpq+JZmBGy9VrjzmSTKXT32YYiHgnFqQWuPJb5mMld8ZCFsy2DMDOCWNyLydWBQBHKQkx4t c1VYK1pdyfex4/wsKjYh2SdJSkPVjgzbEjVy69ibxJz2zmlWlLgKUNoAXS0eQ9pLNa1crQfepGkIH cKtejkQg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tAt8O-0000000Ea84-0B0X; Tue, 12 Nov 2024 15:48:52 +0000 Date: Tue, 12 Nov 2024 15:48:51 +0000 From: Matthew Wilcox To: Kemeng Shi Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RESEND V2 0/5] Fixes and cleanups to xarray Message-ID: References: <20241111215359.246937-1-shikemeng@huaweicloud.com> <20241111132816.3dcbb113241353e9a544adab@linux-foundation.org> <8667a8e9-8052-4a32-817a-2c4ef97ddfbe@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8667a8e9-8052-4a32-817a-2c4ef97ddfbe@huaweicloud.com> X-Stat-Signature: cxo781hwb781sgx8kmezun9bzz1dzocq X-Rspam-User: X-Rspamd-Queue-Id: D8BEC40006 X-Rspamd-Server: rspam02 X-HE-Tag: 1731426517-32279 X-HE-Meta: U2FsdGVkX19uddGuyWSYQvJVBDTAwg58YT1gI7pA+BGRcSJM1iq1L5POgsqKOuYSjthbe5/ooG1RmyKnjYSsWGmed8Ssx93aNcW+ZY/BMVqZIpoIuY12+XmFFT3URP6dIaUgPVfkrXNxnadRHMrU5wGVnhBH5B+5vFj64gjH7EidEUVSKyShvPHAOK97RU2tGXSfhiKQlZnlbCQze0CYBISTq/ElsFfxvkB2Bcl2rTR3Qch8y/3KYu9UwY5CYMbSlyZ5FWfBN5o5KE4YHqY/7RUYPPwYsoEeT79fhB/L4OfLuYdPAqeMl/A/OFsywRZM+vQH7IFB1YUTSnVBwUnOkGD6FfC/J2bZwFYTgmZmLMX0q83IIz7sPvnkwdgTJjcvtJg7KiHhMbaezxmmx61JX3YCtTuFsBtZxxQRxYPUCrJmSbCOawHXv3i7sw6aZlkhDoUzNKVAtaA/H7wkZl+7MB1KUPwu1AdLA/QJTenAF+igqolI03x0xf5FL2dp2rDfE4Dgrho3tikEIWjMI7Bag9kxsO0fceNZ7+afqrgrl+UGHP1qvKB0WKKF6vniEyi0KC6glgA6uQTIA9Ed+gl/T+VagwrPz7wKzymBKUPGefgKbBPEJVaKD0SWQTZZEQk6MVJl5aZj4ou7PRy+/Vd5T0PJOdvTsdaHf/PWNP6G+0MpZyt3YMQBLkorKlNuZACwDEwA0sjmVkUhJ6Xt31af/ZKHKFSQNmzfaZK3QounkCnfZnQpWeXKjls4nNn+uRS+lDKr+iTajuKYhmJ5BZzxJLUmgsaw1PyWjKJQ2B/4Dri2V6T6NWUpysL2aOyey01RhPajiBGnAz5/EZBZRr0YVGbvT0YO8sX2gX2UqocU6EB7LPHdPF43jiDWl3heuXBvX1fYO0lL48LytBhpdn0fccRX8RNKGfuXptoVH8R6C54F4PyHkFE8U1LoXUoGQ3oizSw9b6dSw9I/8qOyCXQ 8CVfVY7I HMLP0/a+FjOYTMOvYAZCkPfAVxJqwhtSKpfra66T77J/QLg4bn8+afMV5sprZnP6lGTMg35FyVqLYStd6Awn5Zxz7/vtYPQAR7KAPbtH3pDk40dczPZHN1xWW4PsBP/uAr9dwQLGxBarV31Hc36ufuwHtzvlDrFvM2YV0p0UlKtvAaxV4C/J3N9I0qlCdYcan8RogmS6viDBX/lQv3nOgwQkLhD4ZBgcaoIuo 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 Tue, Nov 12, 2024 at 03:05:51PM +0800, Kemeng Shi wrote: > Patch 1 fixes the issue that xas_find_marked() will return a sibling entry > to users when there is a race to replace old entry with small range with > a new entry with bigger range. The kernel will crash if users use returned > sibling entry as a valid entry. > For example, find_get_entry() will crash if it gets a sibling entry from > xas_find_marked() when trying to search a writeback folios. You _think_ this can happen, or you've observed a crash where it _has_ happened? I don't think it can happen due to the various locks we have. I'm not opposed to including this patch, but I don't think it can happen today. > Patch 3 fixes the issue that xas_pause() may skip some entry unepxectedly > after xas_load()(may be called in xas_for_each for first entry) loads a > large entry with index point at mid of the entry. So we may miss to writeback > some dirty page and lost user data. How do we lose user data? The inode will still contain dirty pages. We might skip some pages we should not have skipped, but they'll be caught by a subsequent pass, no?