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 9BA79C3ABCE for ; Mon, 16 Sep 2024 04:21:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B28D6B0089; Mon, 16 Sep 2024 00:21:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 962786B008A; Mon, 16 Sep 2024 00:21:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 829DC6B008C; Mon, 16 Sep 2024 00:21:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 65DD56B0089 for ; Mon, 16 Sep 2024 00:21:04 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BE12A1A022C for ; Mon, 16 Sep 2024 04:21:03 +0000 (UTC) X-FDA: 82569301206.05.96DA2C8 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf22.hostedemail.com (Postfix) with ESMTP id AB421C0003 for ; Mon, 16 Sep 2024 04:21:01 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=fr21NHsU; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726460406; a=rsa-sha256; cv=none; b=TzwMNSOdLS3N5DgR/2Gf12wSLcTQwlrJtJFxLx200XooOsEdDWO6ZUVeDLi4belwR9YebK FPo/G2PNZae/R246OX6zwzO/f139MrFif8G+PJOHndgltLSECxQXBaGcN8vdyHpWONIfYo IIRJL/2bn2YzciPW5cqtkkZ9j7EyVxQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=fr21NHsU; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726460406; 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=jwnw+7buV/Co6cDy6nKRIoLyua67GCD7ZNv0sYBhUOM=; b=1awtIV0sUMeuBTsTtUmX95wVBw+MmT2qI1Zm6lM/hZRJpZDYFc+IEK6r/jZjfr6nrUKuEq HgdxMfFYtU/zPAygWBVjAIHyscRdhqjwMHfRTWZKY21U84BIQWykU2XkxKunaRynwgVDCx ACe8AtwfgmO6pEuXHHpH+sktIWHok6A= Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a83562f9be9so419103066b.0 for ; Sun, 15 Sep 2024 21:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1726460460; x=1727065260; 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=jwnw+7buV/Co6cDy6nKRIoLyua67GCD7ZNv0sYBhUOM=; b=fr21NHsUls9MQYFH/r8yzOmx0SWwOcdYkgf08KKsLjs7dcWCtIy9ok37Eg+45g3Jix yam4HBpH0eJwBnajxN0IJin/Dv9GXFbLgPAYfwQOS3wl7GPK85yg71RlWbdSHE5F6BbA 3G9FIGyveOP2gl48AzVoFt5I4cbdV1+XEz3ug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726460460; x=1727065260; 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=jwnw+7buV/Co6cDy6nKRIoLyua67GCD7ZNv0sYBhUOM=; b=RqD0B9jxsuaKJAPJk/lNluWwQjHsNmszGsFssPQRMcW95AWT5XQwATRTXlvhkwD/Ll kZ0MSQ0hbZNTYy3ACwMG00CYdYsVEswsEWjiReJvPqH4RG5Bv7Ib7N+9WnW3EMYEnwIs Mq3zOeCwojxRYkkX3A6uz0PMgUTX++FPeJBrZtJSzceltbkNvFhsUjHvWuKXdDCqbXId L9lueFrFusBueNaACw/HVFwtYHAE6W+AFkZiSAKXoBxGC78td9qch+kVdVg010rIYeUm n4MmG/QQ4s4bb0SejTrOXCepTQaTJtCaxyS0LZ6to5XYpO9T88f/vw554Z6LGf8ldlHk AwHg== X-Forwarded-Encrypted: i=1; AJvYcCXMbN302DMcv5pMXzinUjZ8qJoyaRg3SBvqKOcJPUu5i7vyHvMUQjBBTe+itS0kJ0fYONQlL8C2Jg==@kvack.org X-Gm-Message-State: AOJu0YxWYdpZ91q07eRiV1MDrJP3kSzVQdzXHe3zAWzCn3z4gIlJOcGJ ThYxUmp9wEs5eKAZqOTummWfCA93+k00WIyfe+GuXt2et4Z6F8d20V+Ty1SNRZ0cbmlj/9eMYKc s5k1eUw== X-Google-Smtp-Source: AGHT+IHlU/s3oFPJYKCYyKO7oP0Ar5s4p3KLZbBifsZ7G1xF5hlPc3b/Nf/yoTbDV8ZxQeNBUUB1nQ== X-Received: by 2002:a17:907:e668:b0:a8d:4e26:c9b9 with SMTP id a640c23a62f3a-a902943335emr1351376366b.17.1726460459529; Sun, 15 Sep 2024 21:20:59 -0700 (PDT) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com. [209.85.208.48]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a906109678fsm259522066b.30.2024.09.15.21.20.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Sep 2024 21:20:58 -0700 (PDT) Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5c25f01879fso4600637a12.1 for ; Sun, 15 Sep 2024 21:20:58 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWY2hvSwnFL0UAyavkPSEfN9qm5FmK6qgZCCrhjrVpnDpzPZcr3f6FlNvrthrr28L19kOz2LHj5tw==@kvack.org X-Received: by 2002:a05:6402:2107:b0:5c4:367e:c874 with SMTP id 4fb4d7f45d1cf-5c4367ec9dfmr3443219a12.11.1726460457889; Sun, 15 Sep 2024 21:20:57 -0700 (PDT) MIME-Version: 1.0 References: <0fc8c3e7-e5d2-40db-8661-8c7199f84e43@kernel.dk> In-Reply-To: From: Linus Torvalds Date: Mon, 16 Sep 2024 06:20:40 +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: Dave Chinner Cc: Jens Axboe , Matthew Wilcox , Christian Theune , linux-mm@kvack.org, "linux-xfs@vger.kernel.org" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Dao , clm@meta.com, regressions@lists.linux.dev, regressions@leemhuis.info Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: x87xt5n6qq4kb8655xeeqnb9t3o89p9q X-Rspamd-Queue-Id: AB421C0003 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726460461-405361 X-HE-Meta: U2FsdGVkX1/AVDmo7Ds4g20ZOnjOCBPHEkit1ioeJgHupfOF1+z/pC7kUV4slmYFJ+bL1yQL+W4WiJL/G+OGniEx7rPPqw7Ns/5lLUp3O6Y33jpd5S/liL893hVL810oE4+9jGQErbTNeHtlXWXpZkGe4qxImWMkjU8hAxRynWoEJ5DfUARcSUy8loLH36EpVwX74zFJA+cBXGjL5DUS7obpInFGVOqNwcnTdvTpOhj7wzflKBRIsfOyl15xooxgqAs1VD3uI7ZWPPAV0QXr39/c5FaT4o3hp1/XaWWzckPbwf22uyWzxzKOljCzwBQP5/A1/GeRoLTQzmQs2fjQz+YlMwbZunZ1e76mz/XSF0AdynHlnOsna/xks11HFa6Km0xPGo8NQA6xp+cBZGucJpSyvS1Yj7fm4DlZ07eHiVhutu6nDp21jyKmK1ctuVAtieOsvomxBmZUcJ0TEwmsWNqKo/m/pGWCAEj0VV2VbBwdOJbtx4lyCIU0iJd/g9JdAuDmYj9KwrCT1f62KuJ6qYrob39SprXHfYgxnXIt7d0Bz4TWW4hug2TNGUT9Xkf2BoVOw7/yMkCkrT1BIuVxuyaZE7JgpXk8a6qNW6ZG+G+PwP7S0wsWN0G1pGrcqctHbSvFZlyjCULYkg0Aa0M+mdfzg7sN7+ZfZjRIG7pDpnS5iXM6lU0N548pyqfGdlqfOBwiLypsgmxSz/3gSRdPfzfknDKg3hF5fsyqQnO+n7EU3vxBnNKwlkzXue2b+mSqR7W/IzH58liXYzME8SyB2dt2CkckKle8P2R2BOw5zsLZ+3dJQpgl+2oUfja3UT2cai8P3GH6+LTltny9HQxDODkfCg1sTuLkHOMUaNr1P4EIhnFQykzA+kWQRCHzO8MGfjzgzHb6qbMk23Z/VRRz7N0HnxibNbdFYn4uOowvuDH7uoBMOENwii9Aj98T5X5LaprEJ/pA8c9Iv4xcv+6 IPY5hVMv A3M2kroMv5Gd24SWJLHhFEU1FhGqnTn9rZ1r3v4C3EkCXOwZebVoSTCOUbKH/cT0TR0/prQ7/7cKIcyC2ZNvs9DYFNK+xMsJI+mvRLMFKqLpDrMlhyTGbLxMBivfBtMYhEd2S9Bpx2Kuz91aztVzudkr3kpgi9ff88uwu6MbJT1VcM8i3IeWL3mks6vLt/i9vIWs1sAvED0Su3EWNRpacyWfctc8fZj4U6u2qlW5cUifvxLBZNBK5WT9V0dH5FBKa5tKnJoPo6EmxdhMO11cJE4IMOjbqluU9qfLaBiW4pplVlZFDG3PlXXs3SvtD+pTlWHKhaYAgwi1NO8aNjJr6yDVY6V11MEI/eKXTP4RELJPJ1zYNx8d4AdGxOiaahSOt8Tixv86Fma0dDc7VWkdoW6Vc9RzYApz8SK0hz+vX49aYcc104O77v9t8P8o9xhipdKyxAR/jgBg/2FAzSQtyiWWkQVraHjnZR6Rum4KeO4RaeUeN1/avL5suLkZsMzgrPh0VOrIAlOMJbvlJEEevyGJbYX+GvJXU1NRKfkm1E9iGHV2m4N8/VstvCsKX2GKOxsq3hDAUqrmLio4NKz5Yk9xH/3nWbasHVVsOpFLhUhwFF33xuIZVlOxpQ0ruZbt/DeYIEy3dC5MTBf5M09FmJc8UpUfkI6UuKq7BEwZFfCVf2mA= 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 Mon, 16 Sept 2024 at 02:00, Dave Chinner wrote: > > I don't think this is a data corruption/loss problem - it certainly > hasn't ever appeared that way to me. The "data loss" appeared to be > in incomplete postgres dump files after the system was rebooted and > this is exactly what would happen when you randomly crash the > system. Ok, that sounds better, indeed. Of course, "hang due to internal xarray corruption" isn't _much_ better, but still.. > All the hangs seem to be caused by folio lookup getting stuck > on a rogue xarray entry in truncate or readahead. If we find an > invalid entry or a folio from a different mapping or with a > unexpected index, we skip it and try again. We *could* perhaps change the "retry the optimistic lookup forever" to be a "retry and take lock after optimistic failure". At least in the common paths. That's what we do with some dcache locking, because the "retry on race" caused some potential latency issues under ridiculous loads. And if we retry with the lock, at that point we can actually notice corruption, because at that point we can say "we have the lock, and we see a bad folio with the wrong mapping pointer, and now it's not some possible race condition due to RCU". That, in turn, might then result in better bug reports. Which would at least be forward progress rather than "we have this bug". Let me think about it. Unless somebody else gets to it before I do (hint hint to anybody who is comfy with that filemap_read() path etc). Linus