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 8365FCCD1A0 for ; Wed, 18 Sep 2024 13:52:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1BA16B0082; Wed, 18 Sep 2024 09:52:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCB396B0083; Wed, 18 Sep 2024 09:52:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B93236B0085; Wed, 18 Sep 2024 09:52:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9A56B6B0082 for ; Wed, 18 Sep 2024 09:52:03 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 416F6405D0 for ; Wed, 18 Sep 2024 13:52:03 +0000 (UTC) X-FDA: 82577997726.23.BED4598 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf04.hostedemail.com (Postfix) with ESMTP id 0ABEB4000B for ; Wed, 18 Sep 2024 13:52:00 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W2cJcffR; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726667489; a=rsa-sha256; cv=none; b=SwS6gKHRix3ukGwvb9SoJcMWJ3SEhpbKfHrqghg409QNAbpdw2oQ/VlySpGfH04vSbODEP jmJPaKnOJNrhXL8++I46fQgUIAOok02g12n8VvT/FcghrkIpZT+xVQOMzDZNIR+uXwkzli pXgSgLBTJkh9ylD0aLVh1KDT6+WhL20= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W2cJcffR; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726667489; 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=+OjIl9uDxGAJUC7PJ0lAX4rCR6IE5m7Lsi7Ws5gE7Fw=; b=jsxNXF0Ix30fU7KE9LdX02fUrt4FWfxdtd7KGJVI7dizPVNJiuebCxDfZHwJt7Tbu5V3Du 0+Wbp4aMUIfZFzMmAfFbw8Bi8evhk1nifYe5S92/8wwBPUDRR7gzvgTID8PrCPm9ixVECh 1oHpf1AvWZl94cZl5XPHRN+wKnjDXuE= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5365c060f47so7627634e87.2 for ; Wed, 18 Sep 2024 06:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1726667519; x=1727272319; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+OjIl9uDxGAJUC7PJ0lAX4rCR6IE5m7Lsi7Ws5gE7Fw=; b=W2cJcffRv19C8sKfzjEAqaS4Y/RMlKic0fSYCE9VUDG70clO5cfiOo6XLp2sncDG2W yo3UnkOCxvvOf0qEihcn+s2k3r7x13cWsB1lVyWFXYerbGT1GZAC2cTQsbhoJ6SnYPnN 0lMkVnWtIhoNhyYmOrbUwrvsT570TQk8cpIQA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726667519; x=1727272319; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+OjIl9uDxGAJUC7PJ0lAX4rCR6IE5m7Lsi7Ws5gE7Fw=; b=Bz25j52FIDEZ6EepHpM8dK/Vz5KxIJzxOpcaOwLkCD5U8Pty6ggHcOh0CWz2P8ETOp o5hgUIL8bDynY03NwnaJ/9NRQbUA7bvBUxZhTZEeYJXve+1xLW8Lt2Xr0PG+5DR4QgBz qiQHDGknnm55n+9TOd5d+lqlb77MndXoSAz0IW95gkq/lHRdXkaU4mqF7eleMavCvoi7 TVASdrnU3omOdPuRFrws+R2T/t1qx8+MKLrCYd1tVEFb66pfiKAmJJtRLKsQhZiuv9bq 4FFoBnDzv66XNB2uL+8Q2PsGYqZRULFG5+3YXkIlp/OqqauyUGaJK9AqqgvjkvrBhSp9 jDbg== X-Forwarded-Encrypted: i=1; AJvYcCXSYBUb4xLyeZpGiTXh9VzWRYRXWpcMJCjktV+T53EosPQMoNn/MoCePfG+aoSAtrleaFP/wGiecg==@kvack.org X-Gm-Message-State: AOJu0YwPf44PlCx2+kumam4URQWGguOFgs6AQc0zFEu5Q+dCkx+2HhIN CS5iPl3ZRbNP85+jSbIMX4cRwNk8/aAQl9B194qNDVqJe9Alb7CfbSKuaifCCKm728lehrhHN1i IjVR4Bg== X-Google-Smtp-Source: AGHT+IGifUBMjC+Cen2sKw5fR3R9yHkzyebwVxWLCP+QCB5isVTUDNNgh8AXqEnooH0GK/qx2xxG2Q== X-Received: by 2002:a05:6512:2384:b0:533:1cb8:ec6e with SMTP id 2adb3069b0e04-53678fd1244mr11780902e87.33.1726667518699; Wed, 18 Sep 2024 06:51:58 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-536870b419dsm1525529e87.245.2024.09.18.06.51.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Sep 2024 06:51:57 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5365aec6fc1so7697481e87.3 for ; Wed, 18 Sep 2024 06:51:56 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWE2XIjKfm6b8P2Xk2KaOeWZg2PLSaLpZf6gRDP/MyeiI00gEVXVPC618xP+EDLsZiIr+ul75LfyA==@kvack.org X-Received: by 2002:a05:6512:4019:b0:52e:fc7b:39cb with SMTP id 2adb3069b0e04-53678fce759mr13328998e87.26.1726667516650; Wed, 18 Sep 2024 06:51:56 -0700 (PDT) MIME-Version: 1.0 References: <0fc8c3e7-e5d2-40db-8661-8c7199f84e43@kernel.dk> <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> In-Reply-To: From: Linus Torvalds Date: Wed, 18 Sep 2024 15:51:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Known and unfixed active data loss bug in MM + XFS with large folios since Dec 2021 (any kernel from 6.1 upwards) To: Matthew Wilcox 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 0ABEB4000B X-Rspamd-Server: rspam01 X-Stat-Signature: chqaacdzj893ujfrj588kgrtne71xjse X-HE-Tag: 1726667520-595806 X-HE-Meta: U2FsdGVkX1+UbmP/0i76GcT6/a2EUrUW9Zki2MHd04ce2XlMDtmscvw4mFyQRzfqIynoKJyS9Bu8DR3U4jhkNOIT98NGgAbUjGOl1QDgvW5TY4zB5DzW04UbKsdApc048MHuCjhzX8tSE797G2xoZ+6vx1fDFTNf1IHiTkDKpbwLDeuUsYeCm5ZRmcK6FO5tQusZTBf7tH2Ew3qi97lpdBqZwQII4ATi9Joh/y4UMQADcuxOMkiuD3a9p7gKUYR9uWcW/SmpF1kFBy3rLsy8p7rZR2J2XOquYiWa7gnZIeUWKS704Qkrf+prfBmrse2TZsC4gaTf9xoX5kGGXLKaDYrTYmq/jw/U7rBuB/kE1QsOHlJyUCnvFknjV2ACi7V1JKkNmuGuYAmG6fP7p6/ZZTNnRJyJgwGcmgNAS4KaKXai4hrso0iQD2jRaEud2S28iXoX4Zen5hn9zDTNV8TcKDToij/TMu1mtW5zsRbJ8jgFIhFoaWOECiDF1k4l9rn3J+BIRQ8YUw5FRhvbyzGvKPrCapOlyhcJ4GD41KIPJPANM51UxHTngVDYd2+x0OJBHUjCgt/ODNl1cqZWhJaE/YT0eJr503t9xfsrguei60aCdr/j+xRnfq5AFd3lY3E5hp4v3MX8JYYMz1au/g7RiQnsvz0wKxOWxU69pXPn/Kcq3nITan1owH3oGGBfQP1jYEL+UoGSCE3vWJkWzgAFn4a62nu/YYqO8vhShuBkvjW3LL8ZM7kOrdLuoNIKY8iFSPcSo6OQsgQ9EKzQm+YrHyYMN0azpuTbFvl2Ug5j3tPm4hXsslqh6otINzGMoL1VTq11tzIr9AFXo6/urnBmfKMT1rrmLFC4lq8+kIlSu2bYKACmfZm1SRUcNu7Cq47dj/RNnfuefqW9+TlW5c1EhvYBvIV6cDHAu4xGQE2OHqKGiCVaFaC5PgpjQ/07dNLYl4G6y58vRUIb3lytnz2 U1KU34B/ EK4FZ07awvND/9fBPJsJ1DtDvqbN4jQvXSAXoAhgZtTSlATdt+d24ppUs7vQ4XbWa9H4vlIyyx52lhf5NME1h6+M++fZeXCEZ5ZLls4bfZkMJWM5icMfKptPTFURxR3GoRN/7eGeSrtwyw4C0RZNly90GW/4W+u3juQjcIXoEWHVo347EAJNxMiiDt2ZcWSpLeMW7rgQi89kaLSX1suQq+C0RGOgBKEXRs0wHnM4/XBJ6O2LaCoFUCEZp+yXHl3N77lTUgN0TJeBFmdmRdkODvH0k7nGju3G6NfAkyKh366k+1+42qU4tWQSd7yr5JMufje4BCfu3bfUG1G2V/7zk+3Xq3gQby/E67IuDYkeYTjkj+JhvFVk/qe+jTbEjpr1pUBdqdo0ku3VGQIF9+CUNFxi5sncSdLm85+u9f7EboRtkcSPDmbjt+HKuBVhePkuBMcW7qrNLd39kYzh1B4+0u5hFToDzwZjKduYj6RlSiMdFbYbq3R8RSJypU6EdLGwh/Iski0fZqkRJ+RMBwVv/1HkbvT8rBQiTkSTGTzMA8Km33Xx0/KQFtYZg/x8uazCmcQ2N0vggkSCPGzlxSYkyt3dKlGsxELFKhtORs7sFH+uLYCY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000093, 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, 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. > i wonder if xas_split_alloc() should call xas_reset() to prevent this > from ever being a problem again? See above: I think the code in filemap_add_folio() was buggy entirely unrelated to the xas_split_alloc(), although it is probably *much* easier to trigger issues with it (ie the alloc will just make any races much bigger) But even when it doesn't do the alloc, it takes and drops the lock, and it's unclear how much xas state it just randomly re-uses over the lock drop. (Maybe none of the other operations end up mattering, but it does look very wrong). So I think it might be better to do the xas_reset() when you do the xas_lock_irq(), no? Isn't _that_ the a more logical point where "any old state is unreliable, now we need to reset the walk"? Linus