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 A1A72CEB2CB for ; Mon, 30 Sep 2024 22:44:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2B646B00FD; Mon, 30 Sep 2024 18:43:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB2F8280036; Mon, 30 Sep 2024 18:43:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C04FB6B0106; Mon, 30 Sep 2024 18:43:59 -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 A04006B00FD for ; Mon, 30 Sep 2024 18:43:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 40235804BD for ; Mon, 30 Sep 2024 22:43:59 +0000 (UTC) X-FDA: 82622883798.12.5F11527 Received: from iguana.tulip.relay.mailchannels.net (iguana.tulip.relay.mailchannels.net [23.83.218.253]) by imf14.hostedemail.com (Postfix) with ESMTP id 9DAEC100007 for ; Mon, 30 Sep 2024 22:43:56 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=stgolabs.net header.s=dreamhost header.b=TUY3biKg; arc=pass ("mailchannels.net:s=arc-2022:i=1"); spf=pass (imf14.hostedemail.com: domain of dave@stgolabs.net designates 23.83.218.253 as permitted sender) smtp.mailfrom=dave@stgolabs.net; dmarc=none ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727736110; 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=1w0tpQyukzCFtuLGpM8ycIFWg9JzhAhfgoalyyzoLVQ=; b=RI2GQ2d64bi7SrBF8ZC3S9+wS3Ym5biSkItXiRk+4GjRr/vglqKDWlsU3fUTDWWGmWQGOo BXpf6NdDI367lz4ax+/4qf5rMBI1LbAJAhNxwgnMCJWkzcJmWLRkrU/PyqjozE9+m8b6Lv ki7t/7G4Xcxw5xCdZ2LMFjl1LgoDK2I= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1727736110; a=rsa-sha256; cv=pass; b=auW5lxUfva2sZG/BJLTgf79VcDL7/b8sZMp0KPLyKXf+kMDDZ+mqL7XcruH/FMrQvbO6PF V/8ErYMpd0TzZkOoze2+j1Y0TroOkpKxOSd5s8yMRxQ9LNyDw5YNt37xzEFIuPkiCbn6Np 9i/QPflgzHD2iJ1Hv7Ml8NO7pQ4kJdY= ARC-Authentication-Results: i=2; imf14.hostedemail.com; dkim=pass header.d=stgolabs.net header.s=dreamhost header.b=TUY3biKg; arc=pass ("mailchannels.net:s=arc-2022:i=1"); spf=pass (imf14.hostedemail.com: domain of dave@stgolabs.net designates 23.83.218.253 as permitted sender) smtp.mailfrom=dave@stgolabs.net; dmarc=none X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 40EB4321942; Mon, 30 Sep 2024 22:43:55 +0000 (UTC) Received: from pdx1-sub0-mail-a315.dreamhost.com (100-96-89-39.trex-nlb.outbound.svc.cluster.local [100.96.89.39]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BD29532194D; Mon, 30 Sep 2024 22:43:54 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1727736234; a=rsa-sha256; cv=none; b=muQHMFRXN3C/adqoY/sPI2MLe8tqrQwN5k2w5ZtV2LnBnnjJ8E38rhJlQiFINKlJkLVSaC WvsC5qoErzOk6ITHgIHgKR673/I1zaGqMxox++4xl6it+wy59Zau6+wa3j29QHL9AInRD9 gdk4W/g7i8zSfLydhhLxvQWAec4Ee9WQKDhFEdPDZ5S7JMH7/XUQEmf9bnm4MWRrPMXhKp 09WyxQX4uvchZpJSgEycZeFfLLU8XHB5AKDuE1TkYKFdyLjUzBQub1vbBVj9dvBNO7f5HA rz4xlC6er/GLdbdlhIhQ/qeOhok69kuG7IBkAXJx1vaefj5FpBSun+tixlK8uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1727736234; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1w0tpQyukzCFtuLGpM8ycIFWg9JzhAhfgoalyyzoLVQ=; b=21bMOOT4abstJs3g5nIsvv+BuknM78ZWGyuiLobft8Mvt5qPFavzq7Cvz1KitpV8zXOvng w32pD4fCXl4HjssB5JN+nPE6CEdi1ztFP2h///upLIiDErmc35Lm9i27OhetpUnyReWaMH 72s2hVPwXCA29Uwz1jQ6uFRv2KMSnUlBOAQbVhcs6hpdjMkTXtaVjxN7LyTIDEhWzeToaC OreXqQ+fJqKE5bnW94NM0+EDtiE2nsSfZfjaJSvQ2QAPe2iOPq2PHmiy5oaOFjrCSr1t2r 2htvUmHxptI3bpIbojTgf99U/JxOFnq6+gHlW5tBkAd5apvdxski8Qsbgzpqjg== ARC-Authentication-Results: i=1; rspamd-9d66c6866-nmtlj; auth=pass smtp.auth=dreamhost smtp.mailfrom=dave@stgolabs.net X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Harbor-Broad: 517ec72679099906_1727736235078_1270078056 X-MC-Loop-Signature: 1727736235078:327392066 X-MC-Ingress-Time: 1727736235078 Received: from pdx1-sub0-mail-a315.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.89.39 (trex/7.0.2); Mon, 30 Sep 2024 22:43:55 +0000 Received: from offworld (unknown [104.36.31.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a315.dreamhost.com (Postfix) with ESMTPSA id 4XHbhn6DJ5z2J; Mon, 30 Sep 2024 15:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1727736234; bh=1w0tpQyukzCFtuLGpM8ycIFWg9JzhAhfgoalyyzoLVQ=; h=Date:From:To:Cc:Subject:Content-Type; b=TUY3biKgg42trn3IoLk0/DZp2IMqhEGNxyKNE8+dITdU6gb/z0LzTA5wCGsXwiIfg o18/ad/GiSsE+qskJJwAyXTz9PzBLhasu02jhlAuwL3i9F24o7JmotOiAIpx9SNxiN Ah+5s7XE+m+2mNSuN0A1RfCqr8WK3KiYICuLfIO/8UczWqVju/2azj789TR7luiWda 5SVUsBSBi9kgMYPdgsRqhEBkAy/SKTIgBFqQ4qJqgV0YgA+5BsrnQsNfT7DyyO8v1R MD20KPs2k5x9WwbAz0aZhx4LHOKauxLQ9xcKragDPZhCG3arRKVLd0zGO9pYI9bMql OT1JFYSJTdnEA== Date: Mon, 30 Sep 2024 15:42:27 -0700 From: Davidlohr Bueso To: Matthew Wilcox Cc: Linus Torvalds , Christian Theune , Dave Chinner , Chris Mason , Jens Axboe , 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: Mail-Followup-To: Matthew Wilcox , Linus Torvalds , Christian Theune , Dave Chinner , Chris Mason , Jens Axboe , 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 References: <02121707-E630-4E7E-837B-8F53B4C28721@flyingcircus.io> <295BE120-8BF4-41AE-A506-3D6B10965F2B@flyingcircus.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20240425 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9DAEC100007 X-Stat-Signature: cfa719sudr5n3om47pb54ubpu93nhmff X-HE-Tag: 1727736236-363921 X-HE-Meta: U2FsdGVkX1/B7CtuJV04TJRbcyPV4XvAPxWEKKDdhgVWcrgx9x9HzsRvNsUmq0V+hcWhhn9pbXzZ30+UNyxMTaDAgQS0ZyDq3gnywWjeS1lVhEgbW8CrzKpDc8m8xm7LvbJUVVanB9nwCwWbC0pn743dquKDGXgiGOx7SmhWceBPaIBLYLIBJ4YvaGJrRcg3Rsmw9MOrFCVhpIb7OXkigfS5QMjwLHhMIEpowz92m/+iOosb1422pmsrzweaBB7VdVTNieKCBQ7OpGSLLw6VYR2qfMSRfguQ0v855OQZ5DeIvlIgfwoNzT1x+io83ULGxfDn7iPUwVTnbC0pDhQBgnPxhNeqDUAc+mgbWRX9iHxIC7BTo/sfkzagn3KFZY7QYO+1XHs0hNkgCLD8YIfQ7avF3lT9pe4a0ud/9SQRopiEJf7SPOPkCED7JoGghznrYrUybCkPf8Vo93u6plvuM5wAyBEYYHHj+EEkqXZ7agPkB5Yjv4Rb/txtrlK495GeDSG293Or0LKSUwSeyEUxfw7wmN82d73S1uAwWICujm+gNx14i7PKOHxlNbnYM++L1jfHHacJUlV2WnTaZ7TMXhtUx0Fy3Vx0Ik3hDYZjbzW1fonHchHt4USsYLhzwSl0sfreLqTfp7/MNYu1jDFGjSUGcxuPo0Ud7JUL1AUM5nOWXwcOkthKC89OzKVuzs3hf2mi4JhcndMO7PDzDgo0jpfkVvKfCvDtsylJSjqKxdlK2vHrNXEatGswR7a6+bx4GHA/lifSO5O7MaXkeCgvv6gfun6vYCqQu5XEcLn4mMuki02sjh8haWOQ3zMAf3hPh8zdyv01eaGhaajPEz49cMx7qP33NEBgbLY7A8+aVyeu3kgR3ROPFBVMF33Zf9vrOBMZXyjRmYl1Yjx6eQm29ZSTNLst0tq1ReM5e+n5lGcaVQfAf99BuejgLH2NOUHeCGn2cLDWmxljj3bf8/W NNUcjAxg hK2+dV/e0tl/kPHX8swQBr+Oea3+1wxViIaihzsXMQHt83BlVM5jA0mNkAt2T1WD5LOwigC91f69A3wBgfAdHMOxcollPXMoa/GKzoXDI99D+LupSh4pRPXXhLaP1FbhJtZEVETZdSwsooEZ7eXSHJQbSPIYRNWZbnaV1kv9jIFA1AvguagMS07ktf4R6q/BhMkGw5jp4Ck0SjeWAEeR/kO7xMl07F/vod0rnguB6pZsvhG2CzbFzPc5/1m3TjQFVrTT+PJ39u1QFIiscyxmQ9xTVlizKtB77lJP6sG/SlaoTtEsBsFbYmvJMPH4JYvEuiD/WQNQdtF0JECU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.011072, 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, 30 Sep 2024, Matthew Wilcox wrote:\n >On Mon, Sep 30, 2024 at 01:12:37PM -0700, Linus Torvalds wrote: >> It's basically been that way forever. The code has changed many times, >> but we've basically always had that "wait on bit will wait not until >> the next wakeup, but until it actually sees the bit being clear". >> >> And by "always" I mean "going back at least to before the git tree". I >> didn't search further. It's not new. >> >> The only reason I pointed at that (relatively recent) commit from 2021 >> is that when we rewrote the page bit waiting logic (for some unrelated >> horrendous scalability issues with tens of thousands of pages on wait >> queues), the rewritten code _tried_ to not do it, and instead go "we >> were woken up by a bit clear op, so now we've waited enough". >> >> And that then caused problems as explained in that commit c2407cf7d22d >> ("mm: make wait_on_page_writeback() wait for multiple pending >> writebacks") because the wakeups aren't atomic wrt the actual bit >> setting/clearing/testing. > >Could we break out if folio->mapping has changed? Clearly if it has, >we're no longer waiting for the folio we thought we were waiting for, >but for a folio which now belongs to a different file. > >maybe this: > >+void __folio_wait_writeback(struct address_space *mapping, struct folio *folio) >+{ >+ while (folio_test_writeback(folio) && folio->mapping == mapping) { READ_ONCE(folio->mapping)? >+ trace_folio_wait_writeback(folio, mapping); >+ folio_wait_bit(folio, PG_writeback); >+ } >+} > >[...] > > void folio_wait_writeback(struct folio *folio) > { >- while (folio_test_writeback(folio)) { >- trace_folio_wait_writeback(folio, folio_mapping(folio)); >- folio_wait_bit(folio, PG_writeback); >- } >+ __folio_wait_writeback(folio->mapping, folio); > } Also, the last sentence in the description would need to be dropped. Thanks, Davidlohr