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 142BEC43334 for ; Mon, 27 Jun 2022 15:37:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238755AbiF0PhM (ORCPT ); Mon, 27 Jun 2022 11:37:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238819AbiF0PhE (ORCPT ); Mon, 27 Jun 2022 11:37:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 512551AD92; Mon, 27 Jun 2022 08:37:03 -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 ams.source.kernel.org (Postfix) with ESMTPS id 09C11B8187D; Mon, 27 Jun 2022 15:37:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93DFCC3411D; Mon, 27 Jun 2022 15:36:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656344220; bh=CuWQqDJRWxJQ6RoyWnytqv86/5mnNlfI8V08ozRBjFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cTyii0/1g8OM0TNyfu2I1K6ecK0kjKlapjUP1nhlKneu1qzZn+cM4GzTZsKO08b32 fOldkFG8sR3Ggx0khePLHV63JLu+VXzpLZn3/mTD8Cm1pSaNzLoKO60o/7Xrkk6p92 9ejBxUWiEoUoWj3ImtuJMh4UmBU0i3n+fFqOIKzaBovRZj1r74so+mqbH/C7OV9BNL TUVCP76VntSyT9KLb+Nna9QYxXCW85vDcOFey31DbB9TsyYdzgkJBlkOnD6k/qXTT5 LsCcyxad+npePYbFp6JHYUBqEKF8i95hI6ywxRoiJ3zURfRE9IS2ur7tH15Uennbdz seaO7RMKDoSSw== Date: Mon, 27 Jun 2022 09:36:56 -0600 From: Keith Busch To: Eric Farman Cc: Keith Busch , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, Christian Borntraeger , axboe@kernel.dk, Kernel Team , hch@lst.de, bvanassche@acm.org, damien.lemoal@opensource.wdc.com, ebiggers@kernel.org, pankydev8@gmail.com, Halil Pasic Subject: Re: [PATCHv6 11/11] iomap: add support for dma aligned direct-io Message-ID: References: <20220610195830.3574005-1-kbusch@fb.com> <20220610195830.3574005-12-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 Mon, Jun 27, 2022 at 11:21:20AM -0400, Eric Farman wrote: > > Apologies, it took me an extra day to get back to this, but it is > indeed this pass through that's causing our boot failures. I note that > the old code (in iomap_dio_bio_iter), did: > > if ((pos | length | align) & ((1 << blkbits) - 1)) > return -EINVAL; > > With blkbits equal to 12, the resulting mask was 0x0fff against an > align value (from iov_iter_alignment) of x200 kicks us out. > > The new code (in iov_iter_aligned_iovec), meanwhile, compares this: > > if ((unsigned long)(i->iov[k].iov_base + skip) & > addr_mask) > return false; > > iov_base (and the output of the old iov_iter_aligned_iovec() routine) > is x200, but since addr_mask is x1ff this check provides a different > response than it used to. > > To check this, I changed the comparator to len_mask (almost certainly > not the right answer since addr_mask is then unused, but it was good > for a quick test), and our PV guests are able to boot again with -next > running in the host. This raises more questions for me. It sounds like your process used to get an EINVAL error, and it wants to continue getting an EINVAL error instead of letting the direct-io request proceed. Is that correct? If so, could you provide more details on what issue occurs with dispatching this request? If you really need to restrict address' alignment to the storage's logical block size, I think your storage driver needs to set the dma_alignment queue limit to that value.