Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp1708361pxb; Fri, 10 Sep 2021 11:52:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+X6OPD+39QGHzMUztaasErj3cWIjb76XCN0Tz8ZQE0Tqb8AF9DLr4JeTjhazk6eZDkvm+ X-Received: by 2002:a5d:96da:: with SMTP id r26mr8407515iol.47.1631299932630; Fri, 10 Sep 2021 11:52:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631299932; cv=none; d=google.com; s=arc-20160816; b=OVWydzL2bkJ4iq8cIyQ+JDt/LNP3Y/cjWyH6mj5SgNkuzyyBMcurrBp9RSWdCT8xTC uQ+gJh5g4aVe2fGuZRHa2P9q6vTj/zA6Ppf+ocOoFNnjzP3EREWFHZkb28dHVX7vkiXT RrnxWuJ5oBFsAJEXOLqLNDmCRvaqU4P3HrwHIEDH0Fg6qvlC7JEK4C8dKBbkUdX2wKlw kDLo+jzTCV4RwCMFGAeX/5KvNc8+xlscuqBjQWkhZYYq2bW/SpKim7WT0QWsX+uC+XTK 5bfQ70eqiqcy0UuIB4VVraeO6BuR+MKTDWE6Hx09Z6JxfGOCNWEbxVIJBTj6gz6QXjiK +yeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ZbG02wSQy0cHbtopCQeAWgIzChM7h0PlB1SkuaIGAcs=; b=yR62R8YAT6K4sCJhwFqHjzEJtEHeMS7GEfq8KLyJ3d7iINKIZ8BDylEwIt+6uYWHtr SwmPx2ks1T8As7Y/XvDlwsvBv0w5vDMkfAZ4q2AH4rFYWXdert+Mh3UrwnOiplDxdvGw Yxzh2FjGGcYbJcgLTvntBLXShU2048JCzEMkIXizL6vs55rycoJ11vy8VsAwoS4TJih1 K1lEOOfznrQYCK6QKcPs4mHpO3ojNB0kjKgs5/K47FPDoddFyuJRbHRo9rPPRikItGWY 0/39auMWCiwHiv9JkuiHFNjPBgkMmA14KW6T3ymT/qvUEs7UvezR7FliECRyD4EkKaPW moVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s9si6246800jaj.98.2021.09.10.11.51.59; Fri, 10 Sep 2021 11:52:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232358AbhIJSwI (ORCPT + 99 others); Fri, 10 Sep 2021 14:52:08 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:43852 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229546AbhIJSv6 (ORCPT ); Fri, 10 Sep 2021 14:51:58 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mOlZi-002y21-5p; Fri, 10 Sep 2021 18:48:34 +0000 Date: Fri, 10 Sep 2021 18:48:34 +0000 From: Al Viro To: Linus Torvalds Cc: Jens Axboe , Pavel Begunkov , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [git pull] iov_iter fixes Message-ID: References: <9855f69b-e67e-f7d9-88b8-8941666ab02f@kernel.dk> <4b26d8cd-c3fa-8536-a295-850ecf052ecd@kernel.dk> <1a61c333-680d-71a0-3849-5bfef555a49f@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 10, 2021 at 10:31:00AM -0700, Linus Torvalds wrote: > On Fri, Sep 10, 2021 at 10:26 AM Jens Axboe wrote: > > > > On 9/10/21 10:58 AM, Linus Torvalds wrote: > > > On Fri, Sep 10, 2021 at 9:56 AM Al Viro wrote: > > >> > > >> What's the point of all those contortions, anyway? You only need it for > > >> iovec case; don't mix doing that and turning it into flavour-independent > > >> primitive. > > > > > > Good point, making it specific to iovec only gets rid of a lot of > > > special cases and worries. > > > > > > This is fairly specialized, no need to always cater to every possible case. > > > > Alright, split into three patches: > > > > https://git.kernel.dk/cgit/linux-block/log/?h=iov_iter > > That looks sane to me. > > Please add some comment about how that > > i->iov -= state->nr_segs - i->nr_segs; > > actually is the right thing for all the three cases (iow how 'iov', > 'kvec' and 'bvec' all end up having a union member that acts the same > way). > > But yeah, I like how the io_uring.c code looks better this way too. > > Al, what do you think? I think that sizeof(struct bio_vec) != sizeof(struct iovec): struct bio_vec { struct page *bv_page; unsigned int bv_len; unsigned int bv_offset; }; takes 3 words on 32bit boxen. struct iovec { void __user *iov_base; /* BSD uses caddr_t (1003.1g requires void *) */ __kernel_size_t iov_len; /* Must be size_t (1003.1g) */ }; takes 2 words on 32bit boxen.