From mboxrd@z Thu Jan 1 00:00:00 1970 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 41D131799F for ; Wed, 19 Aug 2026 01:06:58 +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=1787101619; cv=none; b=qs77h1fyKCf1FD789R5WRuS99QWy7v606kje1/P9RYR4zb+rM3GlfUFOLmXPs6is8nCWDSiCYnzBG2dklRxaoxt2oWZ5AH29/fUHYZVxD4PXoFaj1W6SeV7qBKr45YotqXTQjUBEwNY1HpNhmo1tWG+1AScgfj/BwstxfSsvVT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787101619; c=relaxed/simple; bh=qjUvnc0Pz4ExQRj0IR9AWSRxs+gNbNySxuHAeP8PZbY=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=rRGCfGcRJF8VezA7K4DIpXXZFqqd+IKlRbdKCxM354De/CU6iz13HMjpfdFg5jMPhel1JIosVq5mK1+82U3y47hkFyuuXqp3lLOvql+9VcxplV2VdzJJD4qL/vAHTmd55BivGox1lphOAyhnCknYuitheyaYz06RyotOUb6HnXI= 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=d6EGm4UF; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b=a8YhVDch; 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="d6EGm4UF"; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="a8YhVDch" 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 A052D3DFD for ; Wed, 19 Aug 2026 01:06:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1787101611; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qqemY/5/yGTJjC73I/Dnoia7hnNtIpqBquTfALYrxWw=; b=d6EGm4UFSijYyF92dfFLsNSGODdkT6G3vU9E5Y6E1ZWRD3YVOyW87zszXko3MKDqto270K uu/YnlI4o7bwkeVx9yOF19M7BJr7sN700XNqZcX+1X2DWUJJI6Pcd3DIXpnnpWrID9/p6c WwNopzjrTNOudeFyllcegf6nypM7lEc= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1787101607; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qqemY/5/yGTJjC73I/Dnoia7hnNtIpqBquTfALYrxWw=; b=a8YhVDchlOhS11+cqdh8jQYKl0DApdk2qS6IcjwqUEzXp16M2KNCoy/J8cdUgqnmeFq7r2 R1lbqkW6/f1wDKK0UQJj7GzuRtuc0X8lmd1sGwsWPCkHT0tsD31NMNqiVF8Y7t+1c3xSxt Sy2NLBTx3ZdAESOHaI7XMehMHVay87s= 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 882D42F81 for ; Wed, 19 Aug 2026 01:06:46 +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 08vIC6YBhWruVgAAD6G6ig (envelope-from ) for ; Wed, 19 Aug 2026 01:06:46 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH v3 RESEND 0/4] btrfs: removal of on-stack paddrs[], final part Date: Wed, 19 Aug 2026 10:36:15 +0930 Message-ID: X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.80 X-Spam-Level: X-Spam-Flag: NO 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)[-0.999]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; URIBL_BLOCKED(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]; 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)[] [CHANGELOG] v3 RESEND: - Minor commit message change The resend is most for proper sashiko review. v3: - Rebased to the latest for-next There is a fix in RAID56, which can cause conflicts with the last patch - Remove all remaining on-stack paddrs[] usage There are two last ones in RAID56, one can be converted to use bio interface, the other is not using on-stack paddrs[] array. So we can finally remove all on-stack paddrs[] usage. v2: - Fix a missing assignment for metadata repair The logical should be assigned before passing it to btrfs_repair_bbio_failure(). - Move the commit message of error message change to the correct patch It's changed in the first patch not the last one. Since the experimental bs > ps support, several on-stack fixed paddrs[] arrays are introduced, for assemble mutli-page sized fs blocks. However that on-stack memory usage is always there for 4K page sized systems, no matter if the block size of the filesystem. The idea is to use bio interface for page iterations, the core idea is to use a const bvec_iter as the pointer to where the block is. Then we save a local bevc_iter, and use the local iter to check the next few pages until we fill a full block. Furthermore, with the help of bvec_iter, we can remove a lot of parameters: - file_offset - logical - bio_offset All can be generated by using the @iter passed in and the bbio->saved_iter to calculate the old @bio_offset. @bio_offset is the (iter.bi_sector - saved_iter.bi_sector) << SECTOR_SHIFT. As when bvec_iter is advanced, its bi_sector is also increased. @logical is simpler, just iter.bi_sector << SECTOR_SHIFT. @file_offset is the bbio->file_offset + bio_offset. This means we no longer need to use on-stack paddrs[] to csum generation. With bio interfaces, the iteration of an fs block is as simple as the following: (I tried to change the page/pg_off/cur_len into a macro just like btrfs_bio_for_each_block(), but failed) u32 cur = 0; btrfs_csum_init(&cctx, fs_info->csum_type); while (cur < blocksize) { struct page *page = bio_iter_page(&bbio->bio, iter); const u32 pg_off = bio_iter_offset(&bbio->bio, iter); const u32 cur_len = min(bio_iter_len(&bbio->bio, iter), blocksize - cur); void *kaddr; kaddr = kmap_local_page(page) + pg_off; btrfs_csum_update(&cctx, kaddr, cur_len); kunmap_local(kaddr); bio_advance_iter_single(&bbio->bio, &iter, cur_len); cur += cur_len; } btrfs_csum_final(&cctx, csum); However there is still one caller left: - RAID56 That will be only location left without a bio. In that case we can easily craft a local helper to do csum generation without using on-stack paddrs[]. Qu Wenruo (4): btrfs: replace btrfs_repair_io_failure() to use bio for page iteration btrfs: enhance btrfs_data_csum_ok() to use bio for page iteration btrfs: use a shared helper to calculate data checksum for a bio btrfs: remove on-stack paddrs[] array usage fs/btrfs/bio.c | 140 +++++++++++++++++++---------------------- fs/btrfs/bio.h | 5 +- fs/btrfs/btrfs_inode.h | 12 ++-- fs/btrfs/disk-io.c | 25 +++++--- fs/btrfs/file-item.c | 20 ++---- fs/btrfs/inode.c | 114 +++++++++++---------------------- fs/btrfs/raid56.c | 47 ++++++++------ 7 files changed, 159 insertions(+), 204 deletions(-) -- 2.54.0