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,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, 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 A3041C56201 for ; Fri, 23 Oct 2020 21:29:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B973C20FC3 for ; Fri, 23 Oct 2020 21:29:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B973C20FC3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E88406B006C; Fri, 23 Oct 2020 17:29:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3A756B006E; Fri, 23 Oct 2020 17:29:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D28686B0070; Fri, 23 Oct 2020 17:29:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id 9DA556B006C for ; Fri, 23 Oct 2020 17:29:07 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 46FCF180AD81D for ; Fri, 23 Oct 2020 21:29:07 +0000 (UTC) X-FDA: 77404480734.03.stage09_0e13baa2725c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 1D98F28A4E8 for ; Fri, 23 Oct 2020 21:29:07 +0000 (UTC) X-HE-Tag: stage09_0e13baa2725c X-Filterd-Recvd-Size: 6446 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Fri, 23 Oct 2020 21:29:06 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-101-a0KTql5iP42OxX-i9IRDjQ-1; Fri, 23 Oct 2020 22:29:00 +0100 X-MC-Unique: a0KTql5iP42OxX-i9IRDjQ-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; Fri, 23 Oct 2020 22:28:59 +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; Fri, 23 Oct 2020 22:28:59 +0100 From: David Laight To: 'Segher Boessenkool' , Al Viro CC: David Hildenbrand , "linux-aio@kvack.org" , "linux-mips@vger.kernel.org" , David Howells , "linux-mm@kvack.org" , "keyrings@vger.kernel.org" , "sparclinux@vger.kernel.org" , Christoph Hellwig , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "kernel-team@android.com" , Arnd Bergmann , "linux-block@vger.kernel.org" , "io-uring@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jens Axboe , "linux-parisc@vger.kernel.org" , 'Greg KH' , Nick Desaulniers , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.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: AQHWqE5GNDfnH4y9nkGWtfqJueR1KKmjTCJQgAAN4UiAAAD2IIAASOeCgAF+12CAAGD4RoAAL/Bg Date: Fri, 23 Oct 2020 21:28:59 +0000 Message-ID: References: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022104805.GA1503673@kroah.com> <20201022121849.GA1664412@kroah.com> <98d9df88-b7ef-fdfb-7d90-2fa7a9d7bab5@redhat.com> <20201022125759.GA1685526@kroah.com> <20201022135036.GA1787470@kroah.com> <134f162d711d466ebbd88906fae35b33@AcuMS.aculab.com> <935f7168-c2f5-dd14-7124-412b284693a2@redhat.com> <20201023175857.GA3576660@ZenIV.linux.org.uk> <20201023182713.GG2672@gate.crashing.org> In-Reply-To: <20201023182713.GG2672@gate.crashing.org> 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: quoted-printable 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: From: Segher Boessenkool > Sent: 23 October 2020 19:27 >=20 > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote: > > On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote: > > > > > Now, I am not a compiler expert, but as I already cited, at least on > > > x86-64 clang expects that the high bits were cleared by the caller - = in > > > contrast to gcc. I suspect it's the same on arm64, but again, I am no > > > compiler expert. > > > > > > If what I said and cites for x86-64 is correct, if the function expec= ts > > > an "unsigned int", it will happily use 64bit operations without furth= er > > > checks where valid when assuming high bits are zero. That's why even > > > converting everything to "unsigned int" as proposed by me won't work = on > > > clang - it assumes high bits are zero (as indicated by Nick). > > > > > > As I am neither a compiler experts (did I mention that already? ;) ) = nor > > > an arm64 experts, I can't tell if this is a compiler BUG or not. > > > > On arm64 when callee expects a 32bit argument, the caller is *not* resp= onsible > > for clearing the upper half of 64bit register used to pass the value - = it only > > needs to store the actual value into the lower half. The callee must c= onsider > > the contents of the upper half of that register as undefined. See AAPC= S64 (e.g. > > https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#= parameter-passing-rules > > ); AFAICS, the relevant bit is > > =09"Unlike in the 32-bit AAPCS, named integral values must be narrowed = by > > the callee rather than the caller." >=20 > Or the formal rule: >=20 > C.9 =09If the argument is an Integral or Pointer Type, the size of the > =09argument is less than or equal to 8 bytes and the NGRN is less > =09than 8, the argument is copied to the least significant bits in > =09x[NGRN]. The NGRN is incremented by one. The argument has now > =09been allocated. So, in essence, if the value is in a 64bit register the calling code is independent of the actual type of the formal parameter. Clearly a value might need explicit widening. I've found a copy of the 64 bit arm instruction set. Unfortunately it is alpha sorted and repetitive so shows none of the symmetry and makes things difficult to find. But, contrary to what someone suggested most register writes (eg from arithmetic) seem to zero/extend the high bits. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)