On Mon, May 30, 2022 at 12:33:17PM +0300, Jani Nikula wrote:
On Mon, 30 May 2022, Jani Nikula jani.nikula@intel.com wrote:
On Sat, 28 May 2022, Linus Torvalds torvalds@linux-foundation.org wrote:
On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann arnd@arndb.de wrote:
It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this option, you the kernel is built for the old 'OABI' that forces all non-packed struct members to be at least 16-bit aligned.
Looks like forced word (32 bit) alignment to me.
I wonder how many other structures that messes up, but I committed the EDID fix for now.
Thanks for the fix, and the thorough commit message!
This has presumably been broken for a long time, but maybe the affected targets don't typically use EDID and kernel modesetting, and only use some fixed display setup instead.
Those structure definitions go back a _loong_ time (from a quick 'git blame' I see November 2008).
But despite that, I did not mark my fix 'cc:stable' because I don't know if any of those machines affected by this bad arm ABI issue could possibly care.
At least my tree hopefully now builds on them, with the BUILD_BUG_ON() that uncovered this.
Indeed the bug is ancient. I just threw in the BUILD_BUG_ON() on a whim as an extra sanity check when doing pointer arithmetics on struct edid *.
If there are affected machines, buffer overflows are the real danger due to edid->extensions indicating the number of extensions.
That is, for EDID. Makes you wonder about all the other packed structs with enum members across the kernel.
enum should not be used in structures if the layout of the struct matters. ISTR there was a proposal for EABI to make enums just about big enough to hold their enumerated constants - so you'd end up with 8-bit, 16-bit etc according to the largest enumerated value that the compiler thinks it could hold.
That's a latent disaster when enums get used in structs where the layout matters, __packed or not.