linux-kernel - Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 May 2022 21:32:11 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Viresh Kumar <vireshk@...nel.org>,
        Shiraz Hashim <shiraz.linux.kernel@...il.com>,
        Jani Nikula <jani.nikula@...el.com>,
        Ville Syrjälä 
        <ville.syrjala@...ux.intel.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        SoC Team <soc@...nel.org>
Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID
 block count and size helpers")

On Sat, May 28, 2022 at 11:08:48AM -0700, Linus Torvalds wrote:
> This smells like a compiler bug triggered by "there's a 16-bit member
> field in that gtf2 structure, and despite it being packed and aligned
> to 1, we somehow still align the size to 2".

It's an age old thing, it's no compiler bug, and it's completely
compliant with the C standards. Implementations are permitted by the
C standard to pad structures and unions how they see fit - and some
do if it makes sense for performance.

The mistake is that people forget this detail, and they expect
structs and unions to be laid out a certain way - because it doesn't
matter to the same extent on x86.

However, as older ARM CPUs could not do unaligned loads, ensuring
that things were naturally aligned made complete sense, even if it
meant that people who assume the world is x86 got tripped up - the
only way around that would be to make every load very expensive.

It's not "align to size of 2" in OABI, it tends to be align to a
multiple of 4, because the underlying architecture is 32-bit.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!