From patchwork Wed Feb 26 04:10:20 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 13991503 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECAF11A08B8 for ; Wed, 26 Feb 2025 04:10:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543046; cv=none; b=qyfLm9/jxA62K7GaE00caOxG0BhNvlZSZ1fSLfsBJeuRxMitouwcqJ1hvNGbxXNATcP4MyEfKVxHHPOI1+C4JkS26I+8nyRLbtrJEoH6QM4FFODhN6blC3Mv3tGeaQjS73pKYYF3Gv11XXDRrtpHPKV/7oaODf9Fa+B/0RC2Rx8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543046; c=relaxed/simple; bh=coBkDB9n0r1jpLAaB42tNqk/pJRlFyDN+Y9+BMGHq7U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J/79OG468XyI9UK6BnCUL/IZvPZiWnit0j5WUrD76nsrNsrJH3cqbqi9SrDlQglWlQ4MKWW9LnrKtJpHrHD8O6cXiFfWC0U22WSZ0quxZnkwo/N5GEe6FjQ/AgNs4P0kJ/XcOfyKfMF9xBYYD7yTcwzNgQO/m1mEABGyrqw3J4E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=gRDzGBDO; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=gRDzGBDO; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="gRDzGBDO"; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="gRDzGBDO" Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 083962118D; Wed, 26 Feb 2025 04:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543043; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d+V4KTRT5MUI9x14wC6uGTEtGtf2wXvVLjU/Vh5BAxw=; b=gRDzGBDOWuytyxCtKy15/2nDDlm/kpc3lO4Sjo25qTlFmTSiLNVMMcASV1ApYlrKQ8yaNz bvizYqGfwfuN/j+liKblPCndNs7Wvuf7Az9ZbqcLEcboVXpqOgeZNZZhhxX3uYpwXs0LvA wiEmvp2BydibZLa2bcm/DFtvOdEXmY4= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543043; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d+V4KTRT5MUI9x14wC6uGTEtGtf2wXvVLjU/Vh5BAxw=; b=gRDzGBDOWuytyxCtKy15/2nDDlm/kpc3lO4Sjo25qTlFmTSiLNVMMcASV1ApYlrKQ8yaNz bvizYqGfwfuN/j+liKblPCndNs7Wvuf7Az9ZbqcLEcboVXpqOgeZNZZhhxX3uYpwXs0LvA wiEmvp2BydibZLa2bcm/DFtvOdEXmY4= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id F0F0B1377F; Wed, 26 Feb 2025 04:10:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id qCSUK0GUvmcgfQAAD6G6ig (envelope-from ); Wed, 26 Feb 2025 04:10:41 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Cc: stable@vger.kernel.org Subject: [PATCH 1/3] btrfs: subpage: do not hold subpage spin lock when clearing folio writeback Date: Wed, 26 Feb 2025 14:40:20 +1030 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Level: X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FUZZY_BLOCKED(0.00)[rspamd.com]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spam-Score: -2.80 X-Spam-Flag: NO [BUG] When testing subpage block size btrfs (block size < page size), I hit the following spin lock hang on x86_64, with the experimental 2K block size support: _raw_spin_lock_irq+0x2f/0x40 wait_subpage_spinlock+0x69/0x80 [btrfs] btrfs_release_folio+0x46/0x70 [btrfs] folio_unmap_invalidate+0xcb/0x250 folio_end_writeback+0x127/0x1b0 btrfs_subpage_clear_writeback+0xef/0x140 [btrfs] end_bbio_data_write+0x13a/0x3c0 [btrfs] btrfs_bio_end_io+0x6f/0xc0 [btrfs] process_one_work+0x156/0x310 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10 kthread+0xef/0x250 ? finish_task_switch.isra.0+0x8a/0x250 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [CAUSE] It's a self deadlock with the following sequence: btrfs_subpage_clear_writeback() |- spin_lock_irqsave(&subpage->lock); |- folio_end_writeback() |- folio_end_dropbehind_write() |- folio_unmap_invalidate() |- btrfs_release_folio() |- wait_subpage_spinlock() |- spin_lock_irq(&subpage->lock); !! DEADLOCK !! We're trying to acquire the same spin lock already held by ourselves. This has never been reproducibled on aarch64 as it looks like some x86_64 specific folio reclaim behavior? [FIX] Move the folio_end_writeback() call out of the spin lock critical section. And since we no longer have all the bitmap operation and the writeback flag clearing happening inside the critical section, we must do extra checks to make sure only the last one clearing the writeback bitmap can clear the folio writeback flag. Fixes: 3470da3b7d87 ("btrfs: subpage: introduce helpers for writeback status") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo --- fs/btrfs/subpage.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/subpage.c b/fs/btrfs/subpage.c index 4d1bf1124ba0..3ce3d7093ddb 100644 --- a/fs/btrfs/subpage.c +++ b/fs/btrfs/subpage.c @@ -466,15 +466,21 @@ void btrfs_subpage_clear_writeback(const struct btrfs_fs_info *fs_info, struct btrfs_subpage *subpage = folio_get_private(folio); unsigned int start_bit = subpage_calc_start_bit(fs_info, folio, writeback, start, len); + bool was_writeback; + bool last = false; unsigned long flags; spin_lock_irqsave(&subpage->lock, flags); + was_writeback = !subpage_test_bitmap_all_zero(fs_info, folio, writeback); bitmap_clear(subpage->bitmaps, start_bit, len >> fs_info->sectorsize_bits); - if (subpage_test_bitmap_all_zero(fs_info, folio, writeback)) { + if (subpage_test_bitmap_all_zero(fs_info, folio, writeback) && + was_writeback) { ASSERT(folio_test_writeback(folio)); - folio_end_writeback(folio); + last = true; } spin_unlock_irqrestore(&subpage->lock, flags); + if (last) + folio_end_writeback(folio); } void btrfs_subpage_set_ordered(const struct btrfs_fs_info *fs_info, From patchwork Wed Feb 26 04:10:21 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 13991504 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 152AB20AF8E for ; Wed, 26 Feb 2025 04:10:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543053; cv=none; b=ApH8r4pJTVHHxEEbb2XUTeZ0ecl6BJsML6Wq+RiO3IN/3S1jKToDXkNNaPgvPBJg5SUyN1fN9znu36GvUMCmkgRy5naiFCsuz5+TVOwIpKZOh1jtPzzVSSLIOULi2agwzTvMJ0ortQrMy3QFL2EGA+MkMv1/Z1tSdukyjQj0RGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543053; c=relaxed/simple; bh=M0SYU0Kqvy65ZZJ9hm65kUIimvw4ImW+7kunbV4PefU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=efddhAJdzkW6l0WofkHthpxUIfrHERuDOPRzZuCy8C2YygBG3Rw2pdNqcLvkKljlPC0zCwoE8UUKyxfY3TVWvcUNrrsIrNej+cMGkBbHx7oKR/dsbYs24l1WxcMh0AGH1d9uKph4ht1uI6XywXoDO7uI3ZNRQQOFo/maPUlPU0w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=GUTmSd+2; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=GUTmSd+2; arc=none smtp.client-ip=195.135.223.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="GUTmSd+2"; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="GUTmSd+2" Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4C1081F388 for ; Wed, 26 Feb 2025 04:10:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543044; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Yc0010MY4CpdL3BwixsiB/JtMmdfmNGIO2wfUUSSEZo=; b=GUTmSd+23CjJJExzIScc8CSoJnsUrezEdpMCdWzq/7icnB8w5RYFr3Zi2ALBDbG2ABrUwU IfeoCQtfEBvZPlSWpkU/G9/zQ1eDFJdpHa4/DEIYEw0LRFVAm/SkOC6lyHCJpvRr4B8wzA fHVIk6iv2i7LkQjgXbyHZJ7lsKoVEp0= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543044; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Yc0010MY4CpdL3BwixsiB/JtMmdfmNGIO2wfUUSSEZo=; b=GUTmSd+23CjJJExzIScc8CSoJnsUrezEdpMCdWzq/7icnB8w5RYFr3Zi2ALBDbG2ABrUwU IfeoCQtfEBvZPlSWpkU/G9/zQ1eDFJdpHa4/DEIYEw0LRFVAm/SkOC6lyHCJpvRr4B8wzA fHVIk6iv2i7LkQjgXbyHZJ7lsKoVEp0= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7F6281377F for ; Wed, 26 Feb 2025 04:10:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id cHnjD0OUvmcgfQAAD6G6ig (envelope-from ) for ; Wed, 26 Feb 2025 04:10:43 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/3] btrfs: properly limit inline data extent according to block size Date: Wed, 26 Feb 2025 14:40:21 +1030 Message-ID: <0d96520065cd566b81804bf972adf69767bd4528.1740542375.git.wqu@suse.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Score: -2.80 X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-btrfs@vger.kernel.org]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Level: Btrfs utilizes inline data extent for the following cases: - Regular small files - Symlink files And "btrfs check" detects any file extents that are too large as an error. It's not a problem for 4K block size, but for the incoming smaller block sizes (2K), it can cause problems due to bad limits: - Non-compressed inline data extents We do not allow a non-compressed inline data extent to be as large as block size. - Symblinks Currently the only real limit on symblinks are 4K, which can be larger than 2K block size. These will result btrfs-check to report too large file extents. Fix it by adding proper size checks for the above cases. Signed-off-by: Qu Wenruo --- fs/btrfs/inode.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 4629706485dc..386e700515ca 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -570,6 +570,13 @@ static bool can_cow_file_range_inline(struct btrfs_inode *inode, if (size > fs_info->sectorsize) return false; + /* + * We do not allow a non-compressed extent to be as large + * as block size. + */ + if (data_len >= fs_info->sectorsize) + return false; + /* We cannot exceed the maximum inline data size. */ if (data_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info)) return false; @@ -8673,7 +8680,12 @@ static int btrfs_symlink(struct mnt_idmap *idmap, struct inode *dir, struct extent_buffer *leaf; name_len = strlen(symname); - if (name_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info)) + /* + * Symlink utilize uncompressed inline extent data, which should + * not reach block size. + */ + if (name_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info) || + name_len >= fs_info->sectorsize) return -ENAMETOOLONG; inode = new_inode(dir->i_sb); From patchwork Wed Feb 26 04:10:22 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 13991505 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BBBF6266B6C for ; Wed, 26 Feb 2025 04:10:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543053; cv=none; b=vAyX/6diHSuiWYZVbScd26+ajTSWlpNyq13e3ayfxsMHzxDbaNgN/w/qBxrwI8zbRDCT6nhk4T6gdwcfPBoBu4OJIyhklIqnT4jng7wLrKy8BF4DCFiJdK8AWpt47y0L6JBdSTDGIx8Xoy3XunbDoTlT5MyWYvyVrlbDizOPNIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740543053; c=relaxed/simple; bh=s3/JU27zjV+7frws4hdIX9efskI0iXkfsG2wYoCVaXc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gPJLyI3/hGCQJR3g5DCyX72cUj1zsybZBgZQEVgduhwmIP3mQ3shFOzlv7I76VqaPKVjFtP6Xdeg/kth4XXICZoRLM7q45TR9Gq2eUBgAtoWWLdINle5PGMEemctTWRMwDNst1H/HrAsSQE6gKUudJHg7egoVh7tzITogz35zGo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=W2MUVCeK; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=M+/D/O2e; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="W2MUVCeK"; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="M+/D/O2e" Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9012221195 for ; Wed, 26 Feb 2025 04:10:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543046; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/jj9HRI+jOIEZx365uuzCdaFPwh7Jd9VdBiZfbn0W6I=; b=W2MUVCeK4gnEUtvAvq7V47HU6OlPdBS0uc3agJZra4NhKaTkQZs3XVtujR9qz2R/15xLgF bUyNFkArNY05dYwNa81L2JZ7HFzHR9svG1b684juVjo/YYAbobZAf9pp/ma79Ta3xV80Rf 3AqH+ab674Eiz1qXIdxdOWWEBgZT550= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="M+/D/O2e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1740543045; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/jj9HRI+jOIEZx365uuzCdaFPwh7Jd9VdBiZfbn0W6I=; b=M+/D/O2eDaepYwiI/eXUqroRbsxZq9G/zX+wFeNPD64SpMzsHZbAdtIWarbbdaA0qE6/fs rXF1rV8zXHTaf5NnzZZFbpbK5WiCSRqC29o3bql+dnWlskk0+XoqY2pfRmDDPTkBhUp32l DJI+pxWWDF/XBbBJFiH/an4SYdHvhmI= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C3FC41377F for ; Wed, 26 Feb 2025 04:10:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id YFCnIESUvmcgfQAAD6G6ig (envelope-from ) for ; Wed, 26 Feb 2025 04:10:44 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH 3/3] btrfs: allow debug builds to accept 2K block size Date: Wed, 26 Feb 2025 14:40:22 +1030 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Rspamd-Queue-Id: 9012221195 X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-btrfs@vger.kernel.org]; RCVD_TLS_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim,suse.com:mid]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_BLOCKED(0.00)[rspamd.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[suse.com:+] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO Currently we only support two block sizes, 4K and PAGE_SIZE. This means on the most common architecture x86_64, we have no way to test subpage block size. And that's exactly I have an aarch64 machine dedicated for subpage tests. But this is still a hurdle for a lot of btrfs developers, and to improve the test coverage mostly on x86_64, here we enable debug builds to accept 2K block size. This involves: - Introduce a dedicated minimal block size macro BTRFS_MIN_BLOCKSIZE, which depends on if CONFIG_BTRFS_DEBUG is set. If so it's 2K, otherwise it's 4K as usual. - Allow 4K, PAGE_SIZE and BTRFS_MIN_BLOCKSIZE as block size - Update subpage block size checks to be based on BTRFS_MIN_BLOCKSIZE - Export the new supported blocksize through sysfs interfaces As most of the subpage support is already pretty mature, there is no extra work needed to support the extra 2K block size. Signed-off-by: Qu Wenruo --- fs/btrfs/disk-io.c | 12 +++++++++--- fs/btrfs/fs.h | 12 ++++++++++++ fs/btrfs/subpage.h | 2 +- fs/btrfs/sysfs.c | 3 ++- 4 files changed, 24 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index c0b40dedceb5..6a8368421fbc 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -2446,21 +2446,27 @@ int btrfs_validate_super(const struct btrfs_fs_info *fs_info, * Check sectorsize and nodesize first, other check will need it. * Check all possible sectorsize(4K, 8K, 16K, 32K, 64K) here. */ - if (!is_power_of_2(sectorsize) || sectorsize < 4096 || + if (!is_power_of_2(sectorsize) || sectorsize < BTRFS_MIN_BLOCKSIZE || sectorsize > BTRFS_MAX_METADATA_BLOCKSIZE) { btrfs_err(fs_info, "invalid sectorsize %llu", sectorsize); ret = -EINVAL; } /* - * We only support at most two sectorsizes: 4K and PAGE_SIZE. + * We only support at most 3 sectorsizes: 4K, PAGE_SIZE, MIN_BLOCKSIZE. + * + * For 4K page sized systems with non-debug builds, all 3 matches (4K). + * For 4K page sized systems with debug builds, there are two block sizes + * supported. (4K and 2K) * * We can support 16K sectorsize with 64K page size without problem, * but such sectorsize/pagesize combination doesn't make much sense. * 4K will be our future standard, PAGE_SIZE is supported from the very * beginning. */ - if (sectorsize > PAGE_SIZE || (sectorsize != SZ_4K && sectorsize != PAGE_SIZE)) { + if (sectorsize > PAGE_SIZE || (sectorsize != SZ_4K && + sectorsize != PAGE_SIZE && + sectorsize != BTRFS_MIN_BLOCKSIZE)) { btrfs_err(fs_info, "sectorsize %llu not yet supported for page size %lu", sectorsize, PAGE_SIZE); diff --git a/fs/btrfs/fs.h b/fs/btrfs/fs.h index 8e8ac7db1355..b8c2e59ffc43 100644 --- a/fs/btrfs/fs.h +++ b/fs/btrfs/fs.h @@ -47,6 +47,18 @@ struct btrfs_subpage_info; struct btrfs_stripe_hash_table; struct btrfs_space_info; +/* + * Minimal data and metadata block size. + * + * Normally it's 4K, but for testing subpage block size on 4K page systems, + * we allow DEBUG builds to accept 2K page size. + */ +#ifdef CONFIG_BTRFS_DEBUG +#define BTRFS_MIN_BLOCKSIZE (SZ_2K) +#else +#define BTRFS_MIN_BLOCKSIZE (SZ_4K) +#endif + #define BTRFS_MAX_EXTENT_SIZE SZ_128M #define BTRFS_OLDEST_GENERATION 0ULL diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h index f8d1efa1a227..5327093cf466 100644 --- a/fs/btrfs/subpage.h +++ b/fs/btrfs/subpage.h @@ -70,7 +70,7 @@ enum btrfs_subpage_type { BTRFS_SUBPAGE_DATA, }; -#if PAGE_SIZE > SZ_4K +#if PAGE_SIZE > BTRFS_MIN_BLOCKSIZE /* * Subpage support for metadata is more complex, as we can have dummy extent * buffers, where folios have no mapping to determine the owning inode. diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c index 53b846d99ece..4be612cab10f 100644 --- a/fs/btrfs/sysfs.c +++ b/fs/btrfs/sysfs.c @@ -411,7 +411,8 @@ static ssize_t supported_sectorsizes_show(struct kobject *kobj, { ssize_t ret = 0; - /* An artificial limit to only support 4K and PAGE_SIZE */ + if (BTRFS_MIN_BLOCKSIZE != SZ_4K && BTRFS_MIN_BLOCKSIZE != PAGE_SIZE) + ret += sysfs_emit_at(buf, ret, "%u ", BTRFS_MIN_BLOCKSIZE); if (PAGE_SIZE > SZ_4K) ret += sysfs_emit_at(buf, ret, "%u ", SZ_4K); ret += sysfs_emit_at(buf, ret, "%lu\n", PAGE_SIZE);