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 0AA5AC433F5 for ; Fri, 17 Dec 2021 13:54:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236884AbhLQNyW (ORCPT ); Fri, 17 Dec 2021 08:54:22 -0500 Received: from gate.crashing.org ([63.228.1.57]:60104 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231667AbhLQNyV (ORCPT ); Fri, 17 Dec 2021 08:54:21 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 1BHDZQmf021580; Fri, 17 Dec 2021 07:35:26 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 1BHDZJZQ021573; Fri, 17 Dec 2021 07:35:19 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 17 Dec 2021 07:35:18 -0600 From: Segher Boessenkool To: David Laight Cc: Ard Biesheuvel , "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 Message-ID: <20211217133518.GR614@gate.crashing.org> References: <20210514100106.3404011-1-arnd@kernel.org> <20211216185620.GP614@gate.crashing.org> <698cfc52a0d441f7b9f29424be82b2e8@AcuMS.aculab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <698cfc52a0d441f7b9f29424be82b2e8@AcuMS.aculab.com> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On Fri, Dec 17, 2021 at 12:34:53PM +0000, David Laight wrote: > 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 *'. No, see 6.3.2.3/7. Both are allowed (and behave the same in fact). > 'char' is special in that 'strict aliasing' doesn't apply to it. > (Which is actually a pain sometimes.) That has nothing to do with it. Yes, you can validly access any memory as a character type, but that has nothing to do with what pointer casts are allowed and which are not. > > 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.) Not so. For example you are explicitly allowed to have pointers one past the last element of an array (and do arithmetic on that!), and of course null pointers are a thing. C allows you to make up pointers from integers as well. This is perfectly fine to do. Accessing anything via such pointers might well be not standard C, of course. > Indirecting any other pointer is probably UB! If a pointer points to an object, indirecting it gives an lvalue of that object. It does not matter how you got that pointer, all that matters is that it points at a valid object. > 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. This is 6.5/7. Alignment is 6.2.8 but it doesn't actually come into play at all here. > So while *(unaligned_ptr *)char_ptr probably has to work. Only if the original pointer points to an object that is correct (including correctly aligned) for such an lvalue. > 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. It is undefined behaviour to have an address in int_ptr that is not correctly aligned for whatever type it points to. Segher