[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <699073ad09bf4882861003a5da6d6b3c@AcuMS.aculab.com>
Date: Fri, 16 Oct 2020 08:24:38 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Ian Rogers' <irogers@...gle.com>, "hpa@...or.com" <hpa@...or.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86 <x86@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
"Josh Poimboeuf" <jpoimboe@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
"Adrian Hunter" <adrian.hunter@...el.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Numfor Mbiziwo-Tiapo <nums@...gle.com>
Subject: RE: [PATCH v2] x86/insn, tools/x86: Fix some potential undefined
behavior.
From: Ian Rogers
> Sent: 15 October 2020 22:47
...
> The decoder is a shared code and using unaligned macros makes life
> hard for the other users of the code. Memcpy is the "standard"
> workaround for this kind of undefined behavior.
> https://lore.kernel.org/lkml/e4269cb2-d8e6-da26-6afd-a9df72d4be36@intel.com/
You can't always use memcpy() to copy unaligned data.
If the compiler can find any reason why the misaligned address
should be aligned (eg because it's type prior to some casts
requires alignment) it will use word-sized accesses that will fault.
Now in this specific code the pointers are probably all 'char *'
so have alignment 1 - so memcpy() will DTRT.
But it may generate an expensive function call.
There are 'read unaligned 32bit' (etc) macros out there.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists