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 3BC02C19F32 for ; Mon, 3 Mar 2025 00:04:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D55C6B007B; Sun, 2 Mar 2025 19:04:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 985386B0083; Sun, 2 Mar 2025 19:04:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 826376B0085; Sun, 2 Mar 2025 19:04:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 65A036B007B for ; Sun, 2 Mar 2025 19:04:40 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 127E21407F4 for ; Mon, 3 Mar 2025 00:04:40 +0000 (UTC) X-FDA: 83178293520.13.489CFFA Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by imf28.hostedemail.com (Postfix) with ESMTP id DD577C0008 for ; Mon, 3 Mar 2025 00:04:37 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=j3xb1OZ5; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.20 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com; dmarc=pass (policy=quarantine) header.from=gmx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740960278; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=qzXgsvvVGV5i0DC+uMqLAlLy9jtXPt3OOl3JbyFacB4=; b=ez/TKJuZEoWHLog89vYR8CBLMFwybH6SSEcHZ/8wGNBVHoLFOBz9lnpGhnPgP5kfOPJv44 CLITfA5Rk6YdtxtM/wRT9X1gmnxwkiFu9Ozn6YfwEmRgQISpyGnAL8C1h/64i+ARVOJatN qwh4a+WLPQbyvUEkwYaB559QdcwtV1I= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=j3xb1OZ5; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.20 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com; dmarc=pass (policy=quarantine) header.from=gmx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740960278; a=rsa-sha256; cv=none; b=NdZYbyH2ZpR3DIcN3QvJQlTW7RxI0T0DNYI7oA/HyEpOK65/0EvgPJpx0/kLW+V436FLcj LR7BFXSLG0f/uvFwk5fTvBAvTZ1SJXlYtbUv6LijeNlC/+W4pjjPBEiPWaz5ZYNSAI2YCl V0KSc/ZleLrDMjfGu9MynaBetBzQBDU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1740960269; x=1741565069; i=quwenruo.btrfs@gmx.com; bh=qzXgsvvVGV5i0DC+uMqLAlLy9jtXPt3OOl3JbyFacB4=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:From:Subject:To: Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=j3xb1OZ5aVzg2lJ7ny2ONyL4IO2eNrknXbyw8j6UpYSlTsUq61o7TazpB8YhUqqQ DZLAwGFfNcIQ5vcYzImJQv5ivhKL3JBUlL31rXvProXQ8cDTTTTNF4VROSpDnKDby 9CN9OuhLB0jdW9O70HjoHEG0x2g7uZDgbeyDpPcjiU2CqAkpL5hgE/sR6f+If/srn kk0dAcqr1zbSZcD0fUvWHWPtf+eMPyXtkEs0uIxhceN4arC9rM8t2Eetv3aa7o473 oYi5BDRVYp0oTkV/B1mlhm/15ZZAtBw8aWaUCTlQtrBTULTgCcFwGP0W3J8ktNnuM llCq0czT8eJJ40ypnQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [172.16.0.191] ([159.196.52.54]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1ML9uU-1tXlss3fJS-00JtsX; Mon, 03 Mar 2025 01:04:29 +0100 Message-ID: <14bd34c8-8fe0-4440-8dfd-e71223303edc@gmx.com> Date: Mon, 3 Mar 2025 10:34:26 +1030 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Qu Wenruo Subject: Calling folio_end_writeback() inside a spinlock under task context? To: Linux Memory Management List , linux-f2fs-devel@lists.sourceforge.net Content-Language: en-US Autocrypt: addr=quwenruo.btrfs@gmx.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNIlF1IFdlbnJ1byA8cXV3ZW5ydW8uYnRyZnNAZ214LmNvbT7CwJQEEwEIAD4CGwMFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCZxF1YAUJEP5a sQAKCRDCPZHzoSX+qF+mB/9gXu9C3BV0omDZBDWevJHxpWpOwQ8DxZEbk9b9LcrQlWdhFhyn xi+l5lRziV9ZGyYXp7N35a9t7GQJndMCFUWYoEa+1NCuxDs6bslfrCaGEGG/+wd6oIPb85xo naxnQ+SQtYLUFbU77WkUPaaIU8hH2BAfn9ZSDX9lIxheQE8ZYGGmo4wYpnN7/hSXALD7+oun tZljjGNT1o+/B8WVZtw/YZuCuHgZeaFdhcV2jsz7+iGb+LsqzHuznrXqbyUQgQT9kn8ZYFNW 7tf+LNxXuwedzRag4fxtR+5GVvJ41Oh/eygp8VqiMAtnFYaSlb9sjia1Mh+m+OBFeuXjgGlG VvQFzsBNBFnVga8BCACqU+th4Esy/c8BnvliFAjAfpzhI1wH76FD1MJPmAhA3DnX5JDORcga CbPEwhLj1xlwTgpeT+QfDmGJ5B5BlrrQFZVE1fChEjiJvyiSAO4yQPkrPVYTI7Xj34FnscPj /IrRUUka68MlHxPtFnAHr25VIuOS41lmYKYNwPNLRz9Ik6DmeTG3WJO2BQRNvXA0pXrJH1fN GSsRb+pKEKHKtL1803x71zQxCwLh+zLP1iXHVM5j8gX9zqupigQR/Cel2XPS44zWcDW8r7B0 q1eW4Jrv0x19p4P923voqn+joIAostyNTUjCeSrUdKth9jcdlam9X2DziA/DHDFfS5eq4fEv ABEBAAHCwHwEGAEIACYCGwwWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCZxF1gQUJEP5a0gAK CRDCPZHzoSX+qHGpB/kB8A7M7KGL5qzat+jBRoLwB0Y3Zax0QWuANVdZM3eJDlKJKJ4HKzjo B2Pcn4JXL2apSan2uJftaMbNQbwotvabLXkE7cPpnppnBq7iovmBw++/d8zQjLQLWInQ5kNq Vmi36kmq8o5c0f97QVjMryHlmSlEZ2Wwc1kURAe4lsRG2dNeAd4CAqmTw0cMIrR6R/Dpt3ma +8oGXJOmwWuDFKNV4G2XLKcghqrtcRf2zAGNogg3KulCykHHripG3kPKsb7fYVcSQtlt5R6v HZStaZBzw4PcDiaAF3pPDBd+0fIKS6BlpeNRSFG94RYrt84Qw77JWDOAZsyNfEIEE0J6LSR/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:F84/npxwE9CFBbiwq8yALJMx94BxGK+jZzvjIXfcblM7k8KTUNq Bs3JyPnWyS5xCAub2UFqyX+rh7wA46t1fJQXPgpfIv9FCVqwV0wKHN7/aHVDs59gz9/ySM/ k1dcjJlaQit+Erl/CBWDBZgcUWkwcfkJASqU5SMElNKFgltaF8em+RPoc9NIIxsXsS5nwDW k26mpypuIzIbfcnFLZN9Q== UI-OutboundReport: notjunk:1;M01:P0:nM599IgYX0c=;1qZuG9rnGmMVQHCl29WVu0kvPrb EzM58H7FWGtS2SKq0tOB8Qh2Sdj+673G21sRSE1lzOXLp+3+QQFSCoUHtFt9iADXkV+006rFc b4VuN/Ls/6HGBX8+RyW+uqcpCk3jtSPGOBnYlO2fnFTlDGta6gJqe7M3SE8e69Rr2gEOvIxfn Fu+4N7URQlHSSgMI1BYNMgkaO8AVx6VrGjElRuW0UobPdj/pVOgRXZc1kyTp1DPDPqD3stXsq m/VwFb48y1Oe3Sm7NpGgzqiaN002EF2HQkmBBeYUoqOo/WrJAcPWG2oQfAhD2QRv0ElwYApSV uRmrNyVYpUf9I9t2ElrGbus19EV5qTsKJlvuYOoScD8k8gN5wFz2fwiFAjD5xTnJxDrVPrQaB lB7KtrtO7QRhAPfaGHnF6idm0QhsUuBKild97sWwCVbGP7e2v5ymJNhqJZwBtvqJPzWUt6cSA F9JLN/7U6umvIYWpt7BmRpR+CqTwJSq0U6J+tCsza+GXX+fsomhUduPSbPV/GUOfa+t13f+bu f6bI8o/ZpHrb+vg7Pd5Gev+/fooddPVeK021RA4RsrqMUs7iGzWq9CeUVVobJKZdbPjXDanAA EqWzlSHY9nt58Cry2bg33kNr8XBSWi9hWGjuIW5Mu6RRhE2yxM8YExQQg16BPV2/X9WceXbuq 79IBrSje9qQ/8H/nHkGj1m5skRi1EEeKgtaks1fz4sQCTvRgAoblC9cXM/QjQP08i1N8mmict z/IMhLzaX0YrorMHSALOfpL3C6G7ZGnIrKqhqn2KPbRgYkf520ACXFynbK9uJiuBbRhM23P9v AJIFPuoeF4EMuHwbCkeNCVrSHS9eK2rX3jtvaaGXOv1yclw/jwcD91Vwz0fWljJ6BjEDYR31C sv47owMQvWQv28E8jWF842Fhs77vxbW9rA3/jC8aWC2uXNnnCvdObeZarSM2jU35wOipi0F1L 1t89aO2SAX/0bcCZG6hxrcEhwWQzrZtmETgcP4FyuU0bcZwoA8oMyRXMiVpr2X+8yIDqpQpDL VIEq4XPnhNW2gdsD4rXkniJN//HmNdjQVaXortYC05kri2UhdyZF+vV9IpKYh+BRRMyOsFxiG yAxOgi7N0iuCTBxOy07MWQfoD1PTv7RHIQTJJEqh8YZiMF89o9SZc98puLVTUwFk6GL9fZxsC skNvQ3516TVBiHJCAX+1bM/HiCSPcJ+Q59K8bwriSWGC2pMauYHgjFGZhH+H18rxehBqqNYBG XiKU/8rp3a4XqDV84O3tkXMUS77lL69w7U93w7CUFU+UJ8OAbgzOAJs28MBNdvDYiYgzkRi2u ZGrER/uScQ+lb51XIl9aq06/UJ8pEuhzmj3t6Y2QICZ2Bot18zAuudKhlBWSEHaYXOmgpCqTs tBogDw+7us6kHtdywDwbSN6LYeCZfmpvmhjWOkOLchNgaa1ALkGTmx0zC2 X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DD577C0008 X-Stat-Signature: 7g15yzzyin4zch4fp5w1q65q9kkqq8xu X-HE-Tag: 1740960277-463118 X-HE-Meta: U2FsdGVkX189EGGkWCxLwMxvIWl+0VNWHKYlCMbmOmGjCBnJIxsQZuiYs7OEi4yRNx+C3DKd0PU1LUBtZ9EFKhfpVoYJ25DEyupOXrEPjnPR9VzoKARQYPhlqGr/JZ2xgAnZJCRK73TLfEwBvlFeRSSlGNCIAJBoMfBc9M2WQUwV4loy1aOIP/wzcMYY8YFlvOSwhahBYpiVEnM7Anh+aReIJiBZGOfnUinsC6/nEtcXWZuLnz+oKuCiSm9ydAnt7OythHesyJmLr3OdIPs9dXNl0gIiPQ3KH7xxqP5G6FBMZ0mULLodATwAWoRgv+ax9BPZJO38m4QMY9O0r9WaNBz+pLwgZugiLb+l8f3dvDxxheSuy44hNz/cTVWdCEgG7VeH6aEXeYgib50+m7GwdKnWXIWamulV26ui3WIAHZFVM0gnJjo5ztrgLRchxix0oqtsvknQozPBQ/o/dW0xOqMtCkNcqrgiwWejN6vspMRWTjMtG/jslJvSUsF8s8FQUaJdsTSlGJsAy15MEUQdqqZINnMEppFwJh4W3Ige7F4HuX6Ls4/ssoVa/JvwwCQHGYogy7wSk8QyS1Dw4Gq24oQZzjsTvJlrOmHFtXUrK6Y2az361nCzdXbPLT3PISmCbrNXc3FXXBrmrrqwPJ+9v77BSsjzTkK+HBDMyOAyA1zLeEQRCt8kZ8xgJQ/nqebJNcgnyabyxZqR3hcEahgxt1tgFekS/u5KtUecvWSXoO2KuNfX7DgRnXfIYUxZaIVs/WLr+q+ThXbUZMrJVW92Cn1s3WSqErJLUFRNmAqTT27sDZuUEjQjJMmLnK52iz1BSk6UgaEe6U5QvX/4IEEAe2vZlVTtpMwd9n3WXGvKwJLvhLzFHwLBqMEiK/4nkLA8smFN/SdI0hkys6bWoiLNwpIX5xcRKfBONnUlgB33Inq3FBjahBXbnXrPEXAeG9E0D2FLVRBujX+Yh7DJ3qR nX00lFFO qtYmusV7xMgGpeUFXk89rfE4b7VV4dZpB7oHImXQqzf3RmbwThLyb+UqEL8sXl0hDihAIsE1Gf2ZgDwPdStx7hpZIU85fAv39ehj3F6xbdMNWY71VYwrriFSD8G9qzIC+BPnw8Ee/NCzF+0n4Sm9iNW/z6v4i+myZekRfO0X6lCR7D/ZPGl1Wuww3+L/pLkabO34T3Rj46wbnRi0B9QURj7nb3jZN2jyIZDD6sH0Y2EFutIr7cLMFchIxtt+qmGVqurmj/PqSQAf5QaAbDfIprnEBaDRhKkTCincsPa4alqmAWrcYM8zfNoj+GrTSZpMh1ZyBldLq1yN/wjobphsY2hPKeM1kIcqtGhUUYANYgwsNpdVfEOF4rbdXtSG5gtgp6+I0p9SVgyFFohJF1vbkCn/JQeIElmauaLaAvgJRnYHD6MKhAcvxynzQcg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000748, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, [SPINLOCK AND END WRITEBACK] Although folio_end_writeback() can be called in an interruption context (by the in_task() check), surprisingly it may not be suitable to be called inside a spinlock (in task context): For example the following call chain can lead to sleep: spin_lock() folio_end_writeback() |- folio_end_dropbehind_write() |- folio_launder() Which can sleep. My question is, can and should we allow folio_end_writeback() inside a spinlock? [BTRFS' ASYNC EXTENT PROBLEM] This is again a btrfs specific behavior, that we have to call folio_end_writeback() inside a spinlock to make sure really only one thread can clear the writeback flag of a folio. I know iomap is doing a pretty good job preventing early finished writeback to clear the folio writeback flag, meanwhile we're still submitting other blocks inside the folio. Iomap goes holding one extra writeback count before starting marking blocks writeback and submitting them. And after all blocks are submitted, reduce the writeback count (and call folio_end_writeback() if it's the last one holding the writeback flag). But the iomap solution requires that, all blocks inside a folio to be submitted at the same time. This is not true in btrfs, due to the design of btrfs' async extent, which can mark the blocks for writeback really at any timing, as we keep the lock of folios and queue them into a workqueue to do compression, then only after the compression is done, we submit and mark them writeback and unlock. If we do not hold a spinlock calling folio_end_writeback(), but only checks if we're the last holder and call folio_end_writeback() out of the spinlock, we can hit the following race where folio_end_writeback() can be called on the same folio: 0 32K 64K |<- AE 1 ->|<- AE 2 ->| Thread A (AE 1) | Thread B (AE 2) =2D-------------------------------------+------------------------------ submit_one_async_extent() | |- process_one_folio() | |- subpage_set_writeback() | | /* IO finished */ | end_compressed_writeback() | |- btrfs_folio_clear_writeback() | |- spin_lock() | | /* this is the last writeback | | holder, should end the | | folio writeback flag */ | |- last =3D true | |- spin_unlock() | | | submit_one_async_extent() | | |- process_one_folio() | | |- subpage_set_writeback() | | | | /* IO finished */ | | end_compressed_writeback() | | |btrfs_folio_clear_writeback() | | | /* Again the last holder */ | | |- spin_lock() | | |- last =3D true | | |- spin_unlock() |- folio_end_writeback() | |- folio_end_writeback() I know the most proper solution would to get rid of the delayed unlock and submission, but mark blocks for writeback without the async extent mechanism completely, then follow the iomap's solution. But that will be a huge change (although we will go that path eventually), meanwhile the folio_end_writeback() inside spinlock needs to be fixed asap. So my question is, can we allow folio_end_writeback() to be called inside a spinlock, at the cost of screwing up the folio reclaim for DONTCACHE? Thanks, Qu