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 B2891C4167D for ; Fri, 17 Dec 2021 12:35:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236355AbhLQMe7 convert rfc822-to-8bit (ORCPT ); Fri, 17 Dec 2021 07:34:59 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:28089 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233917AbhLQMe6 (ORCPT ); Fri, 17 Dec 2021 07:34:58 -0500 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-157-DNhCqrEmMiq0pBhWJMMNWw-1; Fri, 17 Dec 2021 12:34:55 +0000 X-MC-Unique: DNhCqrEmMiq0pBhWJMMNWw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Fri, 17 Dec 2021 12:34:53 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.026; Fri, 17 Dec 2021 12:34:53 +0000 From: David Laight To: 'Segher Boessenkool' , Ard Biesheuvel CC: "linux-wireless@vger.kernel.org" , "Jason A. Donenfeld" , Rich Felker , "linux-sh@vger.kernel.org" , "Richard Russon (FlatCap)" , X86 ML , Amitkumar Karwar , James Morris , Eric Dumazet , Paul Mackerras , linux-m68k , "H. Peter Anvin" , "open list:SPARC + UltraSPARC (sparc/sparc64)" , Stafford Horne , linux-arch , Florian Fainelli , Yoshinori Sato , Russell King , Linus Torvalds , Ingo Molnar , "Geert Uytterhoeven" , Kalle Valo , Vladimir Oltean , Jakub Kicinski , "Serge E. Hallyn" , Jonas Bonn , "Kees Cook" , Arnd Bergmann , Ganapathi Bhat , Stefan Kristiansson , "linux-block@vger.kernel.org" , "openrisc@lists.librecores.org" , Borislav Petkov , "Thomas Gleixner" , Linux ARM , Jens Axboe , "Arnd Bergmann" , John Johansen , Xinming Hu , Vineet Gupta , Nick Desaulniers , Linux Kernel Mailing List , "linux-ntfs-dev@lists.sourceforge.net" , "linux-security-module@vger.kernel.org" , Linux Crypto Mailing List , "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" , "johannes@sipsolutions.net" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , Sharvari Harisangam Subject: RE: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper Thread-Topic: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper Thread-Index: AQHX8q6cJnIWdY3H8E+V3sMdrqJgg6w2m38Q Date: Fri, 17 Dec 2021 12:34:53 +0000 Message-ID: <698cfc52a0d441f7b9f29424be82b2e8@AcuMS.aculab.com> References: <20210514100106.3404011-1-arnd@kernel.org> <20211216185620.GP614@gate.crashing.org> In-Reply-To: <20211216185620.GP614@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: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Segher Boessenkool > Sent: 16 December 2021 18:56 ... > > The only remaining problem here is reinterpreting a char* pointer to a > > u32*, e.g., for accessing the IP address in an Ethernet frame when > > NET_IP_ALIGN == 2, which could suffer from the same UB problem again, > > as I understand it. > > The problem is never casting a pointer to pointer to character type, and > then later back to an appriopriate pointer type. > These things are both required to work. I think that is true of 'void *', not 'char *'. 'char' is special in that 'strict aliasing' doesn't apply to it. (Which is actually a pain sometimes.) > The problem always is accessing something as if it > was something of another type, which is not valid C. This however is > exactly what -fno-strict-aliasing allows, so that works as well. IIRC the C language only allows you to have pointers to valid data items. (Since they can only be generated by the & operator on a valid item.) Indirecting any other pointer is probably UB! This (sort of) allows the compiler to 'look through' casts to find what the actual type is (or might be). It can then use that information to make optimisation choices. This has caused grief with memcpy() calls that are trying to copy a structure that the coder knows is misaligned to an aligned buffer. So while *(unaligned_ptr *)char_ptr probably has to work. If the compiler can see *(unaligned_ptr *)(char *)int_ptr it can assume the alignment of the 'int_ptr' and do a single aligned access. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)