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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F02ACC5517A for ; Thu, 22 Oct 2020 22:07:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A95E524630 for ; Thu, 22 Oct 2020 22:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S368902AbgJVWHI convert rfc822-to-8bit (ORCPT ); Thu, 22 Oct 2020 18:07:08 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:56018 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S368851AbgJVWHI (ORCPT ); Thu, 22 Oct 2020 18:07:08 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-164-7-H9NMQeNwGwZfcU7aRApw-1; Thu, 22 Oct 2020 23:07:03 +0100 X-MC-Unique: 7-H9NMQeNwGwZfcU7aRApw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 22 Oct 2020 23:07:02 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 22 Oct 2020 23:07:02 +0100 From: David Laight To: 'Al Viro' , Nick Desaulniers CC: Arnd Bergmann , Christoph Hellwig , "David Hildenbrand" , Greg KH , "kernel-team@android.com" , Andrew Morton , Jens Axboe , David Howells , "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" Subject: RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Thread-Topic: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Thread-Index: AQHWqE5GNDfnH4y9nkGWtfqJueR1KKmjTCJQgAAN4UiAAAD2IIAAQY5tgAAwVkCAADSfg4AALKrQ Date: Thu, 22 Oct 2020 22:07:02 +0000 Message-ID: References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> <20201022192458.GV3576660@ZenIV.linux.org.uk> In-Reply-To: <20201022192458.GV3576660@ZenIV.linux.org.uk> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org From: Al Viro > Sent: 22 October 2020 20:25 > > On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > > > Passing an `unsigned long` as an `unsigned int` does no such > > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > > calls, no masking instructions). > > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > > at the mainline@1028ae406999), then children calls of > > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > > unmodified, ie. garbage in the upper 32b. > > FWIW, > > void f(unsinged long v) > { > if (v != 1) > printf("failed\n"); > } > > void g(unsigned int v) > { > f(v); > } > > void h(unsigned long v) > { > g(v); > } > > main() > { > h(0x100000001); > } > > must not produce any output on a host with 32bit int and 64bit long, regardless of > the inlining, having functions live in different compilation units, etc. > > Depending upon the calling conventions, compiler might do truncation in caller or > in a callee, but it must be done _somewhere_. Put g() in a separate compilation unit and use the 'wrong' type in the prototypes t() used to call g() and g() uses to call f(). Then you might see where and masking does (or does not) happen. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)