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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86C07C433B4 for ; Sun, 25 Apr 2021 14:16:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C547E600D1 for ; Sun, 25 Apr 2021 14:16:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C547E600D1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 425066B006C; Sun, 25 Apr 2021 10:16:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D6156B006E; Sun, 25 Apr 2021 10:16:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29CB56B0070; Sun, 25 Apr 2021 10:16:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 0ACF66B006C for ; Sun, 25 Apr 2021 10:16:48 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A58C31802EF1A for ; Sun, 25 Apr 2021 14:16:47 +0000 (UTC) X-FDA: 78071090454.28.745D468 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) by imf08.hostedemail.com (Postfix) with ESMTP id 57B1A801A801 for ; Sun, 25 Apr 2021 14:16:25 +0000 (UTC) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lafYp-008Arj-GM; Sun, 25 Apr 2021 14:16:35 +0000 Date: Sun, 25 Apr 2021 14:16:35 +0000 From: Al Viro To: David Howells Cc: linux-fsdevel@vger.kernel.org, Dave Wysochanski , Marc Dionne , "Matthew Wilcox (Oracle)" , Christoph Hellwig , linux-mm@kvack.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Jeff Layton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 01/31] iov_iter: Add ITER_XARRAY Message-ID: References: <161918446704.3145707.14418606303992174310.stgit@warthog.procyon.org.uk> <161918448151.3145707.11541538916600921083.stgit@warthog.procyon.org.uk> <3388475.1619359082@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3388475.1619359082@warthog.procyon.org.uk> X-Stat-Signature: ef9jdfmjiiumrbun8hu6ycm1idhmqbob X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 57B1A801A801 Received-SPF: none (ftp.linux.org.uk>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=zeniv-ca.linux.org.uk; client-ip=142.44.231.140 X-HE-DKIM-Result: none/none X-HE-Tag: 1619360185-537318 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Apr 25, 2021 at 02:58:02PM +0100, David Howells wrote: > But for the moment, I guess I should just add: > > i->iov_offset += bytes; > > to all three (kvec, bvec and xarray)? No. First of all, you'd need ->count updated as well; for kvec and bvec you *REALLY* don't have to end up with ->iov_offset exceeding the size of current kvec or bvec resp.; Bad Shit(tm) happens that way. > > > > @@ -1246,7 +1349,8 @@ unsigned long iov_iter_alignment(const struct iov_iter *i) > > > iterate_all_kinds(i, size, v, > > > (res |= (unsigned long)v.iov_base | v.iov_len, 0), > > > res |= v.bv_offset | v.bv_len, > > > - res |= (unsigned long)v.iov_base | v.iov_len > > > + res |= (unsigned long)v.iov_base | v.iov_len, > > > + res |= v.bv_offset | v.bv_len > > > ) > > > return res; > > > } > > > > Hmm... That looks like a really bad overkill - do you need anything beyond > > count and iov_offset in that case + perhaps "do we have the very last page"? > > IOW, do you need to iterate anything at all here? What am I missing here? > > Good point. I wonder, even, if the alignment could just be set to 1. There's > no kdoc description on the function that says what the result is meant to > represent. Huh? It's the worst alignment of all segment boundaries, what else? As in if (iov_iter_alignment(i) & 1023) // we have something in there that isn't 1K-aligned.