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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 CA7C4C4363D for ; Wed, 23 Sep 2020 14:17:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 49AFD21D92 for ; Wed, 23 Sep 2020 14:17:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 49AFD21D92 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 8282F6B0055; Wed, 23 Sep 2020 10:17:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D7996B005A; Wed, 23 Sep 2020 10:17:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 713CE6B005C; Wed, 23 Sep 2020 10:17:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 597CB6B0055 for ; Wed, 23 Sep 2020 10:17:08 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9066E181AEF00 for ; Wed, 23 Sep 2020 14:17:07 +0000 (UTC) X-FDA: 77294528094.04.deer89_3d1730627157 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 4103A8014BC3; Wed, 23 Sep 2020 14:17:07 +0000 (UTC) X-HE-Tag: deer89_3d1730627157 X-Filterd-Recvd-Size: 3155 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf34.hostedemail.com (Postfix) with ESMTP; Wed, 23 Sep 2020 14:17:06 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL5Zm-004aBB-Mq; Wed, 23 Sep 2020 14:16:54 +0000 Date: Wed, 23 Sep 2020 15:16:54 +0100 From: Al Viro To: Christoph Hellwig Cc: Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , David Laight , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, io-uring@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec Message-ID: <20200923141654.GJ3421308@ZenIV.linux.org.uk> References: <20200923060547.16903-1-hch@lst.de> <20200923060547.16903-4-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200923060547.16903-4-hch@lst.de> 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 Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote: > +struct iovec *iovec_from_user(const struct iovec __user *uvec, > + unsigned long nr_segs, unsigned long fast_segs, Hmm... For fast_segs unsigned long had always been ridiculous (4G struct iovec on caller stack frame?), but that got me wondering about nr_segs and I wish I'd thought of that when introducing import_iovec(). The thing is, import_iovec() takes unsigned int there. Which is fine (hell, the maximal value that can be accepted in 1024), except that we do pass unsigned long syscall argument to it in some places. E.g. vfs_readv() quietly truncates vlen to 32 bits, and vlen can come unchanged through sys_readv() -> do_readv() -> vfs_readv(). With unsigned long passed by syscall glue. AFAICS, passing 4G+1 as the third argument to readv(2) on 64bit box will be quietly treated as 1 these days. Which would be fine, except that before "switch {compat_,}do_readv_writev() to {compat_,}import_iovec()" it used to fail with -EINVAL. Userland, BTW, describes readv(2) iovcnt as int; process_vm_readv(), OTOH, has these counts unsigned long from the userland POV... I suppose we ought to switch import_iovec() to unsigned long for nr_segs ;-/ Strictly speaking that had been a userland ABI change, even though nothing except regression tests checking for expected errors would've been likely to notice. And it looks like no regression tests covered that one... Linus, does that qualify for your "if no userland has noticed the change, it's not a breakage"?