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 0EF2DC433EF for ; Fri, 17 Dec 2021 12:34:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236350AbhLQMe6 convert rfc822-to-8bit (ORCPT ); Fri, 17 Dec 2021 07:34:58 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:49363 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233880AbhLQMe6 (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-sh@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) 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB2A3C433F5 for ; Fri, 17 Dec 2021 12:36:40 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JFpPy6LCdz3cXn for ; Fri, 17 Dec 2021 23:36:38 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.86.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) X-Greylist: delayed 65 seconds by postgrey-1.36 at boromir; Fri, 17 Dec 2021 23:36:09 AEDT Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JFpPP4ms1z2yNw for ; Fri, 17 Dec 2021 23:36:09 +1100 (AEDT) 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 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: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A. Donenfeld" , Rich Felker , "linux-sh@vger.kernel.org" , "Richard Russon \(FlatCap\)" , linux-m68k , Amitkumar Karwar , Russell King , Eric Dumazet , "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" , Paul Mackerras , "H. Peter Anvin" , "open list:SPARC + UltraSPARC \(sparc/sparc64\)" , Thomas Gleixner , linux-arch , Nick Desaulniers , Florian Fainelli , X86 ML , James Morris , Ingo Molnar , Geert Uytterhoeven , Linux ARM , Vladimir Oltean , Jakub Kicinski , "Serge E. Hallyn" , Jonas Bonn , Kees Cook , Arnd Bergmann , Ganapathi Bhat , "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" , Stefan Kristiansson , "linux-block@vger.kernel.org" , "openrisc@lists.librecores.org" , Borislav Petkov , Stafford Horne , Kalle Valo , Jens Axboe , Arnd Bergmann , John Johansen , Xinming Hu , Yoshinori Sato , "linux-wireless@vger.kernel.org" , Linux Kernel Mailing List , "linux-ntfs-dev@lists.sourceforge.net" , "linux-security-module@vger.kernel.org" , Linux Crypto Mailing List , Vineet Gupta , "johannes@sipsolutions.net" , Linus Torvalds , Sharvari Harisangam Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 =3D=3D 2, which could suffer from the same UB problem agai= n, > > as I understand it. >=20 > 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. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Laight Date: Fri, 17 Dec 2021 12:34:53 +0000 Subject: [OpenRISC] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper In-Reply-To: <20211216185620.GP614@gate.crashing.org> References: <20210514100106.3404011-1-arnd@kernel.org> <20211216185620.GP614@gate.crashing.org> Message-ID: <698cfc52a0d441f7b9f29424be82b2e8@AcuMS.aculab.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.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)