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 83F2BCCD1B3 for ; Wed, 18 Sep 2024 14:12:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11C176B0082; Wed, 18 Sep 2024 10:12:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CC9D6B0083; Wed, 18 Sep 2024 10:12:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED58D6B0085; Wed, 18 Sep 2024 10:12:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CF3646B0082 for ; Wed, 18 Sep 2024 10:12:39 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7EC3814062E for ; Wed, 18 Sep 2024 14:12:39 +0000 (UTC) X-FDA: 82578049638.16.43B10FA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 693C1C0014 for ; Wed, 18 Sep 2024 14:12:36 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HNeVUv6i; spf=none (imf28.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=1726668725; 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=Ni/akaMESxhEbLiyAWV6aj2aPhfND/QItwuWAkzArog=; b=4/OmNYvmTkveQgySF2tD5xfu1Eu/O8HsmxYRQnXvb3bb8vybJFJblnYsBt1imHnEDUVZM3 Q3tgrFx8OZ9ek7tkuRv9JoawroJQvMeasIvet6shnhdVAGIOdkIsDjkwGEODFn6VVjKuwN DlOlHrkTRCkVphbYxVDb8hDhc3wZho8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HNeVUv6i; spf=none (imf28.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726668725; a=rsa-sha256; cv=none; b=rDN+RjExA/4d8bwoLc4LBtyZKFPv7S5jVmKGkTV1Jm2hhOCUpkC55ywBhCPVbzccEukvcH 7tBJarvNAXOU6OyKsZomr6sscsUgFRXfrj7bFp/hqbZGEbwmHQ4Phbp/0p5yPJ0kZLS75f DASi+9RGLqmG1Xe8zYsx/RBM3/VEiHg= 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=Ni/akaMESxhEbLiyAWV6aj2aPhfND/QItwuWAkzArog=; b=HNeVUv6iwFCo/iQBMWywvV3X+F 3k8CBU7k+sHoZOahkAZyNNbUcNMseYbno1kbdALrlcNhSr/fCjzk3TsjYfdRIPDxo27yzb0MQkU8/ wp6Owt6JTPKWq/29Bq043kYpK2LYzWP5Fnhkjo6IDmh5F8mxnzc8Rx/7oFcblMJyoThQbntw9OzFm vOaHlGQ3WX3a2FFku+S2m8JTnFl72JNv1dYquzJE/weqFVE3iymBho4wx0cCrugR+pTvMrY0km8m6 85Jdk2A4+J/L+RznjV0ud0aPOudzZfKoiLAA9BzrHCZuV/CggzefYbZaEETK2RWCWygnhfDfVJlmO sYLL9rOQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1sqvQ0-00000005cxD-0wKA; Wed, 18 Sep 2024 14:12:32 +0000 Date: Wed, 18 Sep 2024 15:12:31 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Chris Mason , Jens Axboe , Dave Chinner , Christian Theune , linux-mm@kvack.org, "linux-xfs@vger.kernel.org" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Dao , regressions@lists.linux.dev, regressions@leemhuis.info Subject: Re: Known and unfixed active data loss bug in MM + XFS with large folios since Dec 2021 (any kernel from 6.1 upwards) Message-ID: References: <74cceb67-2e71-455f-a4d4-6c5185ef775b@meta.com> <52d45d22-e108-400e-a63f-f50ef1a0ae1a@meta.com> <5bee194c-9cd3-47e7-919b-9f352441f855@kernel.dk> <459beb1c-defd-4836-952c-589203b7005c@meta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 7idnh1ignsh7ob64kfp4qr18wqc3knxy X-Rspamd-Queue-Id: 693C1C0014 X-Rspamd-Server: rspam11 X-HE-Tag: 1726668756-770431 X-HE-Meta: U2FsdGVkX1+crv6U5ZWTqTqOMemiuW9wXaSGV3ky6MZQvWDEgP+c2V1JPbgYSYq134qiP2MVWvUF41zDCiTqPj7G/TLVMcRSYNtji9437kHM92chaLvxxHl/WSLihhwzZc4b/WAlwM+1rffdSMANXPDoQCbHp6cWe8d7mifFoI2rAxc8Hyt/AFrsPSaI9cVhZHofVYmNMWrOkZaRqvMslMT9qJrhgtZgsA60cJIo+WCdSVTYtzPLj4w2/bU5akAlrDWzDGtR5B8MfsvkCGdOJaSicw7EZhEacVezpHIcX37Eo9nihmacxWKTqC8JnNqd+0FpsJiFxL60lxEZ6r5Z1ZjTHeQJvifmee/k4TgIxFKQo5LZcf4B+RlTIYD3Zb4JwkkYvy0j7AoXKNglV21yOnF0Rh0aNcPxzMd6Ok0tjpnLMDxHgKtEKOBeFNSTtZd18a+SmwpyIvOWjXVfqUhMWqJyF8Q2jEaeqN3QiWFiWG28shlHnyBzp767B1naFUPcCeXT5S2Zu6/9OZTpDN6dke9lGXsMSc6F6SxQLAWBW6q0aO15O5wK2wkwPqhb65fJzRtSd8qylKEognSdWcw7fhssYW57xPnpMZrTJwiIWoSHVrixqsBDA50kSe6q8XapNv+4QMZLdYeaoVt6yZxUVhhk9m7tXUtukX0pJIX3s4wjT9gBI8jnSEfpspOml8o51VPqfs9qQLUL/715XJSNUKNY7kykoGDkxJD2PMnttj9dLNzdwxfwYXfZdbr9QK3fwPQwgTiNvubmb9j6nWrY5ZveFiTKUO+C9cmyjh4QYYJPxFTSwLNKNCLCFiS/B9IhgSN3IjmDqTiSSfEbQBuIeGg48Xn90mIh6L/uo4kDqvoUt7YSsfKwF7f5vCRX6W/PwdopEBRGPpgDqWXDKdX26n7QEds+ILj1xJSoyq2MUHN4mzZ/3Bf8XtFJMkbHIGvR3uyNYm/3PMl4DJLY4ed kZVJQu0g Q70cKSA9b4y7QGnTFFIvk32L8HybQZBH25w23eFdQ24ncQt/jooJLEysjgw1vgG3ZdXUNiis0Hn34CqZmhn9GokwYyeCWKBn7/bGAi6apOCU4lzC3uBKq+nonzBhCFy2DprYWuyZQgwJXhEwyFtrZgeSqyPkL3JRH3mOOwn3Fquyeh/N+lR3ev+kwQ6Pmhh99lrOd+tcBknAhmO32ViYydYNBYVxEdSa/qOpc/KnwQDv2S7L61yYsJEB+g4hvZ6k8/R5lopzLf3cRW3kyoQmHH+aVBA4u7cMV/igfmmp3BpNfXZ0fMGfFwkkI/7yuGReOfWemSweEMmGus0A= 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 Wed, Sep 18, 2024 at 03:51:39PM +0200, Linus Torvalds wrote: > On Wed, 18 Sept 2024 at 15:35, Matthew Wilcox wrote: > > > > Oh god, that's it. > > > > there should have been an xas_reset() after calling xas_split_alloc(). > > I think it is worse than that. > > Even *without* an xas_split_alloc(), I think the old code was wrong, > because it drops the xas lock without doing the xas_reset. That's actually OK. The first time around the loop, we haven't walked the tree, so we start from the top as you'd expect. The only other reason to go around the loop again is that memory allocation failed for a node, and in that case we call xas_nomem() and that (effectively) calls xas_reset(). So in terms of the expected API for xa_state users, it would be consistent for xas_split_alloc() to call xas_reset(). You might argue that this API is too subtle, but it was intended to be easy to use. The problem was that xas_split_alloc() got added much later and I forgot to maintain the invariant that makes it work as well as be easy to use.