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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 279D8C36010 for ; Mon, 7 Apr 2025 07:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=POTZZTFx8e7Qjfm9uneUvYFWborPRmcyfdRQFUuGvK8=; b=Xpbb7ZY2oq6Fgg AgO1BSoyc5euECHyWQbRnsYU0x6R7D03metQOvwOPAqo2l3QLKpMKMKHXI2Pz8T15lzVVpWdvsjhB YP2MtWphokjX5PCQ5xQ5evwvYotXpw0iBj4JE0eZIPE7QAyTMtXstY9sejM6u7KpoTjuX0XFPsis7 +un5Q96fft7zssNBJwsC38TzWhwTo6myndJ025ueaZx4ex+iFfDa00/RgQjFzFxQSKlEkfe7+lC1q 5GWsK6amzLgH8daLyu/jexD00SxmGHpM6mbEEkpKTku0W7e7T+Mt2UEHkQ/U6n0YeS4YUYTQoovZ/ Re0/rWlbxUJQydNhtWPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1u1gZe-0000000Gg4x-3NCQ; Mon, 07 Apr 2025 07:07:14 +0000 Received: from hch by bombadil.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1u1gZb-0000000Gg4g-3afm; Mon, 07 Apr 2025 07:07:11 +0000 Date: Mon, 7 Apr 2025 00:07:11 -0700 From: Christoph Hellwig To: Sean Anderson Cc: Jens Axboe , linux-block@vger.kernel.org, Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, Zhihao Cheng Subject: Re: bio segment constraints Message-ID: References: <8dfd97ac-59e7-ae69-238a-85b7a2dae4f1@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8dfd97ac-59e7-ae69-238a-85b7a2dae4f1@gmail.com> X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Sun, Apr 06, 2025 at 03:40:04PM -0400, Sean Anderson wrote: > Hi all, > > I'm not really sure what guarantees the block layer makes regarding the > segments in a bio as part of a request submitted to a block driver. As > far as I can tell this is not documented anywhere. In particular, First you need to define what segment you mean. We have at least two and a half historical uses of the name. One is for each bio_vec attached to the bio, either directly as submitted into ->submit_bio for bio based drivers (case 1a), or generated by bio_split_to_limits (case 1b), which is called for every blk-mq driver before calling into ->queue_rq(s) or explicitly called by a few bio based driver. The other is the bio-vec synthesized by bio_for_each_segment (case 2). > - Is bv_len aligned to SECTOR_SIZE? Yes. > - To logical_sector_size? Yes. > - What if logical_sector_size > PAGE_SIZE? Still always aligned to logical_sector_size. > - What about bv_offset? bv_offset is a memory offset and must only be aligned to the dma_alignment limit. > - Is it possible to have a bio where the total length is a multiple of > logical_sector_size, but the data is split across several segments > where each segment is a multiple of SECTOR_SIZE? Yes. > - Is is possible to have segments not even aligned to SECTOR_SIZE? No. > - Can I somehow request to only get segments with bv_len aligned to > logical_sector_size? For drivers that use bio_split_to_limits implicitly or explicitly you can do that by setting the right seg_boundary_mask. > make some big assumptions (which might be bugs?) For example, in > drivers/mtd/mtd_blkdevs.c, do_blktrans_request looks like: > - There is only one bio in a request. This one is a bit of a soft > assumption since we should only flush the pages in the bio and not the > whole request otherwise. It always operates on the first bio in the request and then uses blk_update_request to move the context past that. It is an old and somewhat arkane way to write drivers, but should work. The rq_for_each_segment looks do call flush_dcache_page look horribly wrong for this model, though. > - The data is in lowmem OR bv_offset + bv_len <= PAGE_SIZE. kmap() only > maps a single page, so if we go past one page we end up in adjacent > kmapped pages. Yes, this looks broken. > Am I missing something here? Handling highmem seems like a persistent > issue. E.g. drivers/mtd/ubi/block.c doesn't even bother doing a kmap. > Should both of these have BLK_FEAT_BOUNCE_HIGH? BLK_FEAT_BOUNCE_HIGH needs to go away rather sooner than later. in the short run the best fix would be to synthesized a bio_for_each_segment like bio_vec that stays inside a single page using bio_iter_iovec) at the top of do_blktrans_request and use that for all references to the data. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/