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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1659BC433EF for ; Thu, 19 May 2022 01:53:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232262AbiESBxP (ORCPT ); Wed, 18 May 2022 21:53:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229995AbiESBxP (ORCPT ); Wed, 18 May 2022 21:53:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56094C5E6E; Wed, 18 May 2022 18:53:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F0AF061839; Thu, 19 May 2022 01:53:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 215ECC385A5; Thu, 19 May 2022 01:53:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652925193; bh=aR9cS75tdLbbSx+T3PLo+uQZ1YiTcPLqyagxqI8zzkk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M+0sDSn6M7YqlZAJOe5uP7318UVtZq1YUyEtcz2GbCbPvBWRYjoxmoY8iVrfUzg/T 4f29LFZHO+WVZbsh8groIyO94Xa345t5ZBnywUW3uTmpHyHCJ759oUSTVPMfrXLy3O vEum7NNX0bVx7LQ1+1dKYQkJbcJ0LZz+twtaS6EGZEy08vij39aeCH+SmG1Z3HHgRg wl4hTyyTpK1G+KD/Q+LtCP37/EO/5Ku2U/Z6jX/m7/SgNTb2DunuQrSMlZRMyJ3OrK qN2YBkL5ErJLCF5/OsHRZ80l9YuxTJLHNeytD7Emer9jHEIfjkXF94tBBy085UuNEj K/dw/LN6DLOrg== Date: Wed, 18 May 2022 18:53:11 -0700 From: Eric Biggers To: Keith Busch Cc: Keith Busch , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, axboe@kernel.dk, Kernel Team , hch@lst.de, bvanassche@acm.org, damien.lemoal@opensource.wdc.com Subject: Re: [PATCHv2 3/3] block: relax direct io memory alignment Message-ID: References: <20220518171131.3525293-1-kbusch@fb.com> <20220518171131.3525293-4-kbusch@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, May 18, 2022 at 07:00:39PM -0600, Keith Busch wrote: > On Wed, May 18, 2022 at 05:14:49PM -0700, Eric Biggers wrote: > > On Wed, May 18, 2022 at 10:11:31AM -0700, Keith Busch wrote: > > > diff --git a/block/fops.c b/block/fops.c > > > index b9b83030e0df..d8537c29602f 100644 > > > --- a/block/fops.c > > > +++ b/block/fops.c > > > @@ -54,8 +54,9 @@ static ssize_t __blkdev_direct_IO_simple(struct kiocb *iocb, > > > struct bio bio; > > > ssize_t ret; > > > > > > - if ((pos | iov_iter_alignment(iter)) & > > > - (bdev_logical_block_size(bdev) - 1)) > > > + if ((pos | iov_iter_count(iter)) & (bdev_logical_block_size(bdev) - 1)) > > > + return -EINVAL; > > > + if (iov_iter_alignment(iter) & bdev_dma_alignment(bdev)) > > > return -EINVAL; > > > > The block layer makes a lot of assumptions that bios can be split at any bvec > > boundary. With this patch, bios whose length isn't a multiple of the logical > > block size can be generated by splitting, which isn't valid. > > How? This patch ensures every segment is block size aligned. No, it doesn't. It ensures that the *total* length of each bio is logical block size aligned. It doesn't ensure that for the individual bvecs. By decreasing the required memory alignment to below the logical block size, you're allowing logical blocks to span a page boundary. Whenever the two pages involved aren't physically contiguous, the data of the block will be split across two bvecs. > > Also some devices aren't compatible with logical blocks spanning bdevs at all. > > dm-crypt errors out in this case, for example. > > I'm sorry, but I am not understanding this. I meant to write bvecs, not bdevs. - Eric