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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 540B8C47BD8 for ; Tue, 6 Jan 2026 10:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 774966B008A; Tue, 6 Jan 2026 05:05:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 71ABD6B0093; Tue, 6 Jan 2026 05:05:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF436B0095; Tue, 6 Jan 2026 05:05:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 48F046B008A for ; Tue, 6 Jan 2026 05:05:52 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CA8231B4CF for ; Tue, 6 Jan 2026 10:05:51 +0000 (UTC) X-FDA: 84301107702.08.778BD26 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf08.hostedemail.com (Postfix) with ESMTP id F1C58160002 for ; Tue, 6 Jan 2026 10:05:49 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="dp/tW1qp"; spf=pass (imf08.hostedemail.com: domain of david@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=david@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1767693950; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7bzH3NK4Uu8cfYQRDJ0IbIrNVOl2O3KL2y8eO7FudBE=; b=ndjaYEVtff8hQjwqWDZxVRUyi7zFrv1PVUoapZdFCbySYp4kSX92veQZzHFCcQ/taYK72z HW0WLi262Q5L+RxWLBsMZP8leb+P7lOt5Da8yhOzU//tVaXMrGV65GP0VcS1T6fWIQbGGs Z/yWndan0MbEOhSOvbBd0lzpXniU068= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="dp/tW1qp"; spf=pass (imf08.hostedemail.com: domain of david@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=david@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1767693950; a=rsa-sha256; cv=none; b=ZiiRZYJFXL4PxgOOUWF7e9gVIpO2JMLuAOkZTDAiVHfLNzV5zX/WONFnNWO3AttEGF5udd QMP9bTQ00WPsW+C44V8wHfhsi2j7nd8hzy9Aw/c39a8l9SDHmn8AlVDtck3VpLUpdNz6+K xkSI1oyWf+tSwcmWHJFBYo/XMW2DUo4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id C0620401E9; Tue, 6 Jan 2026 10:05:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6B24C116C6; Tue, 6 Jan 2026 10:05:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767693948; bh=9tJVBrC2RGcJNRIoSkZGDIElVh+JiC6ZoPPf3FqVOlM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dp/tW1qp/Fn5nNEJxl3L2ALhHIsbH5fkOMhMgK13eS9JysC9cfo0Q2yVm4a/A3YYF N5Oaf4+GAH1Ixai+J1sG+GqmTa0PrjbHzA8aVAKBFZCkhfcbxi+aNMQopVmvcbJZm9 ujT2abFFsoJANTNFADnywRjjq26Nlvut6CEccv79YBxRKzyI24GU/IXbuJBtdvoxOK As1ql9Ig58dZ/lTlkt89OkOFNXrp2tY2/W0X8xJaH4fW2G970DE5jL1JDBSPWgROy1 QRrC1oc+T+0W7sDyeVQ+W3LCjfyzrzEIHJu6rVOGWmgHeWhac0AILBLCpZcUVp/LTk fI2hapOqqpJhA== Message-ID: <616c2e51-ff69-4ef9-9637-41f3ff8691dd@kernel.org> Date: Tue, 6 Jan 2026 11:05:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes() To: Jan Kara , Joanne Koong Cc: akpm@linux-foundation.org, miklos@szeredi.hu, linux-mm@kvack.org, athul.krishna.kr@protonmail.com, j.neuschaefer@gmx.net, carnil@debian.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org References: <20251215030043.1431306-1-joannelkoong@gmail.com> <20251215030043.1431306-2-joannelkoong@gmail.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAa2VybmVsLm9yZz7CwY0EEwEIADcWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCaKYhwAIbAwUJJlgIpAILCQQVCgkIAhYCAh4FAheAAAoJEE3eEPcA/4Naa5EP/3a1 9sgS9m7oiR0uenlj+C6kkIKlpWKRfGH/WvtFaHr/y06TKnWn6cMOZzJQ+8S39GOteyCCGADh 6ceBx1KPf6/AvMktnGETDTqZ0N9roR4/aEPSMt8kHu/GKR3gtPwzfosX2NgqXNmA7ErU4puf zica1DAmTvx44LOYjvBV24JQG99bZ5Bm2gTDjGXV15/X159CpS6Tc2e3KvYfnfRvezD+alhF XIym8OvvGMeo97BCHpX88pHVIfBg2g2JogR6f0PAJtHGYz6M/9YMxyUShJfo0Df1SOMAbU1Q Op0Ij4PlFCC64rovjH38ly0xfRZH37DZs6kP0jOj4QdExdaXcTILKJFIB3wWXWsqLbtJVgjR YhOrPokd6mDA3gAque7481KkpKM4JraOEELg8pF6eRb3KcAwPRekvf/nYVIbOVyT9lXD5mJn IZUY0LwZsFN0YhGhQJ8xronZy0A59faGBMuVnVb3oy2S0fO1y/r53IeUDTF1wCYF+fM5zo14 5L8mE1GsDJ7FNLj5eSDu/qdZIKqzfY0/l0SAUAAt5yYYejKuii4kfTyLDF/j4LyYZD1QzxLC MjQl36IEcmDTMznLf0/JvCHlxTYZsF0OjWWj1ATRMk41/Q+PX07XQlRCRcE13a8neEz3F6we 08oWh2DnC4AXKbP+kuD9ZP6+5+x1H1zEzsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCgh Cj/CA/lc/LMthqQ773gauB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseB fDXHA6m4B3mUTWo13nid0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts 6TZ+IrPOwT1hfB4WNC+X2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiu Qmt3yqrmN63V9wzaPhC+xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKB Tccu2AXJXWAE1Xjh6GOC8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvF FFyAS0Nk1q/7EChPcbRbhJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh 2YmnmLRTro6eZ/qYwWkCu8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRk F3TwgucpyPtcpmQtTkWSgDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0L LH63+BrrHasfJzxKXzqgrW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4v q7oFCPsOgwARAQABwsF8BBgBCAAmAhsMFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmic2qsF CSZYCKEACgkQTd4Q9wD/g1oq0xAAsAnw/OmsERdtdwRfAMpC74/++2wh9RvVQ0x8xXvoGJwZ rk0Jmck1ABIM//5sWDo7eDHk1uEcc95pbP9XGU6ZgeiQeh06+0vRYILwDk8Q/y06TrTb1n4n 7FRwyskKU1UWnNW86lvWUJuGPABXjrkfL41RJttSJHF3M1C0u2BnM5VnDuPFQKzhRRktBMK4 GkWBvXlsHFhn8Ev0xvPE/G99RAg9ufNAxyq2lSzbUIwrY918KHlziBKwNyLoPn9kgHD3hRBa Yakz87WKUZd17ZnPMZiXriCWZxwPx7zs6cSAqcfcVucmdPiIlyG1K/HIk2LX63T6oO2Libzz 7/0i4+oIpvpK2X6zZ2cu0k2uNcEYm2xAb+xGmqwnPnHX/ac8lJEyzH3lh+pt2slI4VcPNnz+ vzYeBAS1S+VJc1pcJr3l7PRSQ4bv5sObZvezRdqEFB4tUIfSbDdEBCCvvEMBgoisDB8ceYxO cFAM8nBWrEmNU2vvIGJzjJ/NVYYIY0TgOc5bS9wh6jKHL2+chrfDW5neLJjY2x3snF8q7U9G EIbBfNHDlOV8SyhEjtX0DyKxQKioTYPOHcW9gdV5fhSz5tEv+ipqt4kIgWqBgzK8ePtDTqRM qZq457g1/SXSoSQi4jN+gsneqvlTJdzaEu1bJP0iv6ViVf15+qHuY5iojCz8fa0= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam02 X-Stat-Signature: d5tzcg59odb5c86zq6eud9n481zifdpw X-Rspam-User: X-Rspamd-Queue-Id: F1C58160002 X-HE-Tag: 1767693949-234950 X-HE-Meta: U2FsdGVkX192leGp8Q6bGGHa2Mk5TFq6kOiaiKjF2p9vqlEDJWcFjZLlbJzq37qGBVUavDEO7zjx3T1s0LfcbWys1MRgvBT1+aA2HOjsic0FfYeay7qBY6iU/yDPgFS477bVkD0cZMlSEEeYVT6SZ4Nv5Rs0oxdYQkiVkTFrXjqLKauTEi/PMP3yQWa+xURHz3du4DADgUHt4ixM+L4x0w3tumhiE//qbvmCTnZT6RFNS4HsjdS+Ud2knV/9h7GVS8VCWMPogpRFJD+J5Tli1afeCVkNEaJ2P+0vWeroxkJbylBefeGvZIraDEJGmkD+vH0u6ojWgrIZgRf1NGpHMfryAJIzdUFzw9b00mYGb0JrpFgQLnCG+jFIuZvHTyVNaQlpROU4k90in6iTpQory+Jjw3CuW7Bnhjknw/2Ku5gN2F564yFAehbCHWDdEIxr7cnvQPcDXj3j4hC4aPVix645eyTMbdCqtm0XglF6Ld9PF4Asv56BoJN+DEgBDTzjSeu0RbCk1hfKb1ZdjZBQQ0rRp6VNxbl39b+SRCHzh/1FlnkE+AOAf1X26nn/Cedpro288hUQgHQJFrvrPgnVazfXaEyn923SSEQxztu5+mGMQt7LRVggJagUD6m7Zq/bFB88tAaDmSOF4wkpy7b27rVeecw6V86Zds3x6UUFwr18GXudRstWgQm33FjMe3XkYcY4Vp87yBKeaBWrZAL+fq2ydNc2F2fXlAwzt5/c7AGR71ZU+hiDSlvmPyrjqw+c//c0GLJoi+H2ostX64r9NPEm/X3YI6QC2tNDGc7zRnxPDr0D4QDwSrOuoTb9BIhrkQElIbb5qMscSunCKRTCbzWXEYPwkp1F4M/x3NX2FcenbBH1CpSHzCpZjPekO28ih+7rZXEpDvOyVJWJrC8pFzUWIrhbbSRd+FKNfIeZzLda1bZ1L82ibdKCt8/XDaa0i9zWXVQM5U6JrhAgg3s Hrg/CERb zpgwk3/h/2myB7+FAqBODhNecPOJy6u7Sm2So1YSjLHQK3xj3NXzWTH9Wqxnxams//JgI1BQUEH/98cYr6TXhanqVAmDfsF7o7bekTNhNwqOj9nbGclDnkYwRYSF++boO86s6y6EsceabjysosdggvjeMSbIG61TVLQkByLRAwTXTN/GVEIDF4lQdOOWsNdNeDHx/nbcKK9EJqXqM/RrkmgUW697kleboD/FwJf/pZrmmRXTQwFx0ukWpFYClnI2w69ipcSA8GeVUMCiJBLb3sJCSaHnjFFDI5uI5Zmd0nICMzrfjKzv0citE/pOvTzRfhnBpm+9dMg3/Aw9hmwtzg4JarAAodQ6SWfNILYqW0qd+Dcd9YrEp+MTPumMSPJUuokjrlnZw9hJwNQHYRR1s7P6uNi1mtC9/ENeLvTaVPB66NNhRZ9/H9+eRCMS3TbTfVy42Ugffy7jRI3A= 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 1/6/26 10:33, Jan Kara wrote: > [Thanks to Andrew for CCing me on patch commit] > > On Sun 14-12-25 19:00:43, Joanne Koong wrote: >> Skip waiting on writeback for inodes that belong to mappings that do not >> have data integrity guarantees (denoted by the AS_NO_DATA_INTEGRITY >> mapping flag). >> >> This restores fuse back to prior behavior where syncs are no-ops. This >> is needed because otherwise, if a system is running a faulty fuse >> server that does not reply to issued write requests, this will cause >> wait_sb_inodes() to wait forever. >> >> Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") >> Reported-by: Athul Krishna >> Reported-by: J. Neuschäfer >> Cc: stable@vger.kernel.org >> Signed-off-by: Joanne Koong > > OK, but the difference 0c58a97f919c introduced goes much further than just > wait_sb_inodes(). Before 0c58a97f919c also filemap_fdatawait() (and all the > other variants waiting for folio_writeback() to clear) returned immediately > because folio writeback was done as soon as we've copied the content into > the temporary page. Now they will block waiting for the server to finish > the IO. So e.g. fsync() will block waiting for the server in > file_write_and_wait_range() now, instead of blocking in fuse_fsync_common() > -> fuse_simple_request(). Similarly e.g. truncate(2) will now block waiting > for the server so that folio_writeback can be cleared. > > So I understand your patch fixes the regression with suspend blocking but I > don't have a high confidence we are not just starting a whack-a-mole game Yes, I think so, and I think it is [1] not even only limited to writeback [2]. > catching all the places that previously hiddenly depended on > folio_writeback getting cleared without any involvement of untrusted fuse > server and now this changed. Even worse, it's not only untrusted fuse servers, but also trusted-but-buggy fuse servers, unfortunately. As Joanne wrote in v1: " As reported by Athul upstream in [1], there is a userspace regression caused by commit 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") where if there is a bug in a fuse server that causes the server to never complete writeback, it will make wait_sb_inodes() wait forever, causing sync paths to hang. " > So do we have some higher-level idea what is / > is not guaranteed with stuck fuse server? Joanne first proposed AS_WRITEBACK_MAY_HANG, which I disliked [2] for various reasons because the semantics are weird. I am strongly against using such a flag to arbitrarily skip waiting for writeback on folios in the tree. The patch here is at least logically the right thing to do when only looking at the wait_sb_inodes() writeback situation [3] and why it is even ok to skip waiting for writeback, and the fix Joanne originally proposed. To handle the bigger picture (I raised another problematic instance in [4]): I don't know how to handle that without properly fixing fuse. Fuse folks should really invest some time to solve this problem for good. As a big temporary kernel hack, we could add a AS_ANY_WAITING_UTTERLY_BROKEN and simply refuse to wait for writeback directly inside folio_wait_writeback() -- not arbitrarily skipping it in callers -- and possibly other places (readahead, not sure). That would restore the old behavior. Well, not quite, because the semantics that folio_wait_writeback() promises -- writeback flag at least cleared once, like required here for data integrity -- are just not true anymore. And it would still break migration of folios that are under writeback even though waiting for writeback even for migration even though in 99.9999% of all cases with trusted fuse server will do the right thing. Just nasty. Of course, we could set AS_ANY_WAITING_UTTERLY_BROKEN in fuse only conditionally, but the fact that buggy trusted fuse servers are now a thing, it all stops making any sense because we would have to set that flag always. There is no easy way to get back the old behavior without reverting to the old way of using buffer pages I guess. [1] https://lore.kernel.org/linux-mm/504d100d-b8f3-475b-b575-3adfd17627b5@kernel.org/[2] https://lore.kernel.org/linux-mm/f8da9ee0-f136-4366-b63a-1812fda11304@kernel.org/[3] https://lore.kernel.org/linux-mm/6d0948f5-e739-49f3-8e23-359ddbf3da8f@kernel.org/[4] https://lore.kernel.org/linux-mm/504d100d-b8f3-475b-b575-3adfd17627b5@kernel.org/ -- Cheers David