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 09F98C38A02 for ; Fri, 28 Oct 2022 17:06:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231211AbiJ1RGV (ORCPT ); Fri, 28 Oct 2022 13:06:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229917AbiJ1REm (ORCPT ); Fri, 28 Oct 2022 13:04:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D63FC2303DC for ; Fri, 28 Oct 2022 10:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666976530; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/IYuohmEO1F/L2EkVBn4KSHqgkaps/PV3lH1XEHBh2w=; b=GdH0eWLbQIIoW5MORpk+91uMKcw3jz+vMyDlQz6Eir68FT/u0eO2076vq5QgbAA6EUFHnw aZIeXYWyflA/xVx1m1RRLZjuYKHJ4o8KNIpb1xrqxEFi8WMPWG70lrqgynaM+4sayq3ZOm Ef2hH4k5chNr71llkRh1uAailGOwN98= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-319-cCmbhtwaMMW9r-ymwGBz8Q-1; Fri, 28 Oct 2022 13:02:06 -0400 X-MC-Unique: cCmbhtwaMMW9r-ymwGBz8Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B5E602A5957D; Fri, 28 Oct 2022 17:02:05 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.73]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3777640C6EC3; Fri, 28 Oct 2022 17:02:03 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <20221028023352.3532080-1-viro@zeniv.linux.org.uk> <20221028023352.3532080-12-viro@zeniv.linux.org.uk> To: Linus Torvalds Cc: dhowells@redhat.com, Al Viro , Christoph Hellwig , willy@infradead.org, dchinner@redhat.com, Steve French , Shyam Prasad N , Rohith Surabattula , Jeff Layton , Ira Weiny , linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/12] use less confusing names for iov_iter direction initializers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65440.1666976522.1@warthog.procyon.org.uk> Date: Fri, 28 Oct 2022 18:02:02 +0100 Message-ID: <65441.1666976522@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: > Honestly, I think the *real* fix would be a type-based one. Don't do > > iov_iter_kvec(&iter, ITER_DEST, ... > > at all, but instead have two different kinds of 'struct iov_iter': one > as a destination (iov_iter_dst), and one as a source (iov_iter_src), Or maybe something along the lines of iov_iter_into_kvec() and iov_iter_from_kvec()? Also, would it make sense to disallow asking the iterator for its direction entirely and only use it for internal sanity checking? In many of the places it is looked at, the information is also available in another form (the IOCB_WRITE flag, for example). David