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 388E4C3ABA2 for ; Mon, 16 Sep 2024 13:29:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CBC96B008A; Mon, 16 Sep 2024 09:29:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97A936B008C; Mon, 16 Sep 2024 09:29:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8698C6B0092; Mon, 16 Sep 2024 09:29:56 -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 69F126B008A for ; Mon, 16 Sep 2024 09:29:56 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 11F7D1A045A for ; Mon, 16 Sep 2024 13:29:56 +0000 (UTC) X-FDA: 82570684392.14.F369F97 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 5E067A0017 for ; Mon, 16 Sep 2024 13:29:54 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=gNjxOfWA; spf=none (imf15.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=1726493339; 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=qq8tYo1JEcSLEHueBFlP6ppnnitpWT6xJFK+HA9N1s0=; b=ScaD+jkbxdKJcw4ALrn5OPXrf+sytjvooloXjfwolnjXrw4JYphsK4FNEzNXiTwuJ4XlWI 1ehzw6OYRLdv+Z+qVW1vN4IFZXi475DXYQz8/f9xeeMcfvAVnQS5g0GlWgyYS/9mmg3ajH 1Gaqj9jJPcl50l6qHrHUTOoDuMmT+9A= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=gNjxOfWA; spf=none (imf15.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=1726493339; a=rsa-sha256; cv=none; b=IxTdShRSF3O7jVKtGBIwfnrvTxRDN859oVpu9HynTObvPlmdvbp3FlXKK+zc1ONaVmQm98 TOvAkieYxUNPmGhlc3/CZP1FHSYjq76doisnNrsyx4GXKMqcA7RUR/sd7pNk0GnYlaya3e MdutzmRCOj+p6OaXmj+sHwDWDx4C2XA= 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=qq8tYo1JEcSLEHueBFlP6ppnnitpWT6xJFK+HA9N1s0=; b=gNjxOfWAvf+YsKYoElIQn4rni0 6N+tyQGjTWwWB1p4IFbKCksWfwTK7CmArJcHKg5rz91aJxEPAVWecr0Y9M9vejYbwmAoWA2aJCLLB J/uks525IrO4RGWjZAAcuRThdIQ5IHwN8CQFqNDhHmBBqa1uUqK/5D0v7n67gjqh5zI6h/bAT1Mz/ aVUqdsdNInRz+TbFlT0DbUG+6fkXcsQgFiBLTKJ8Z/sJtwJ3JLiZyvP49i+O7mGt1GR9TzYC34oC5 PnSMfQrrNW7qF101SjvfsAZkqcmm2IFYQjVwK9Fb3qIhkBCaTJyXJH+a4dMbUAEVJbMABK9nUyULh HhCf5eYw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1sqBna-00000001zL5-0aWo; Mon, 16 Sep 2024 13:29:50 +0000 Date: Mon, 16 Sep 2024 14:29:49 +0100 From: Matthew Wilcox To: Christian Brauner Cc: Linus Torvalds , Pankaj Raghav , Luis Chamberlain , Jens Axboe , Christian Theune , linux-mm@kvack.org, "linux-xfs@vger.kernel.org" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Dao , Dave Chinner , clm@meta.com, 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: <0fc8c3e7-e5d2-40db-8661-8c7199f84e43@kernel.dk> <20240913-ortsausgang-baustart-1dae9a18254d@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240913-ortsausgang-baustart-1dae9a18254d@brauner> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 5E067A0017 X-Stat-Signature: wx3658amm1gdidrmqp5kdqmex535aynb X-HE-Tag: 1726493394-93993 X-HE-Meta: U2FsdGVkX19QdZ4PsULUmxEyZnAgPge29M2fUl+Jsb2jI5TRO79mR3MkCrknGK2g5vh2coz6jAxc+DkNy0y0/q1aVVEhMoPWd/hew+FaASYdfzVtNwPK2R2QtoN4Rh4W+sKX1fZEljmdkEio/LyAyJBoHWXeIfCNdZBZrKn3Y/E2eHDX+8rdSP7ruw9l6eb6KVcJqlcVxeu0YXpb/REipnKGDSNgYn5t8dVQ3Lo+Ltd81u7h2E1nCnj0pBor/ZVpUp9Ds3iXJIzUyK6SXavI/qKYiSatB8tRFvbWen0sviTVV9S2PX66pJCdJHSg7TcnIajG5bkOgqi2oHHdbTWpzgbcmTgysO32DW4dhKAyLctdoWcYZ26FyHhcokD32jj+dQwn1ZcfLiYSboA61T7wJtF0misDx0dxhcumRpKa7tQ18GDMaQR3HcSNXOpnbAEyhCAfLQ83DVu14RPm7BLKgBtsRCSPtTjCcz7ZJgjbW9ptuhu8QvuaiKRYaKQ4iT1+CSrLl9nqPh+NCoE0WD2gaHFxHw8hJyvLNOyiZnhUSWMnIonI26gpeMxWHqja5OAH0dpvOKzuZn4buxhu9i3QyPyIbzmShUVcLfks05BQULtR9e92ZqPTlIXEKpCJr9o0P4xshodD/HNlX8HNWWXZIBxgJ3KHmDlEgaP+6tkl3rCFU4GXrWksjHtUA7115YCP/Q7RNxA4DsUDPLk24DjDhIxX0tXjvAi+pvvUnSt5v6/VQuetYaRqDoTenOZ7PQu3TRfRUodfXkVLz+Vvg7ai4HuxfizxxomZ/qHvki17VeOglBcbBNQvRV+3H7IbaMxYF4wHZGj/SPu5JfLF8gAzWKAdwDufX/3uwiiMmOz4dQ9FsgASngZRQ15DgKKwwR/ef4qXOTmJ5VkWLDZcM3nO9ZmXSHmWPg+u7y8+kVFTc5QdiJhknU7TF0LcWcVutapjMPt5/ZzPqeyN5zUQoeI 2g/HtB3v 7gZClIE7uiAV+XSYwcPI68yhuReZClfxwm3iorqjtOgxqu6hfxw41ZnK1mKmeTuXjBzOahPzrn70Yhe8wgeAAgk/SBHJ+SHlm3YudwCHCj8jsHIImX46+YKgoSGoynE/PNqFjU63q8/bFLjij7wX+5hIEHYW1RbEtB0r8F3q9yZSPO/kRiSDHM4+c6fK6VmNgI0IwQNxrDfW+X1vsB3dn9JaUCh+7fU48lv4T12VaD8rzMLYE7/3udy19RvbtrC4rh/PTZLL+uYaG0ViKcYPNLZWRGA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001098, 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 Fri, Sep 13, 2024 at 02:11:22PM +0200, Christian Brauner wrote: > So this issue it new to me as well. One of the items this cycle is the > work to enable support for block sizes that are larger than page sizes > via the large block size (LBS) series that's been sitting in -next for a > long time. That work specifically targets xfs and builds on top of the > large folio support. > > If the support for large folios is going to be reverted in xfs then I > see no point to merge the LBS work now. So I'm holding off on sending > that pull request until a decision is made (for xfs). As far as I > understand, supporting larger block sizes will not be meaningful without > large folio support. This is unwarranted; please send this pull request. We're not going to rip out all of the infrastructure although we might end up disabling it by default. There's a bunch of other work queued up behind that, and not having it in Linus' tree is just going to make everything more painful.