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]

Message-Id: <91E67F46-A3C7-4159-9E0C-C6C6306F3669@inria.fr>
Date:   Tue, 31 May 2022 07:26:53 +0100
From:   Julia Lawall <Julia.Lawall@...ia.fr>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jani Nikula <jani.nikula@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Viresh Kumar <vireshk@...nel.org>,
        Shiraz Hashim <shiraz.linux.kernel@...il.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 30 May 2022, at 15:27, Arnd Bergmann <arnd@...db.de> wrote:
> 
> On Mon, May 30, 2022 at 4:08 PM Jani Nikula <jani.nikula@...el.com> wrote:
>>> On Mon, 30 May 2022, Arnd Bergmann <arnd@...db.de> wrote:
>>> struct my_driver_priv {
>>>       struct device dev;
>>>       u8 causes_misalignment;
>>>       spinlock_t lock;
>>>       atomic_t counter;
>>> } __packed; /* this annotation is harmful because it breaks the atomics */
>> 
>> I wonder if this is something that could be caught with coccinelle. Or
>> sparse. Are there any cases where this combo is necessary? (I can't
>> think of any, but it's a low bar. ;)
>> 
>> Cc: Julia.
> 
> I think one would first have to make a list of data types that are not
> meant to be in a packed structure. It could be a good start to
> search for any packed aggregates with a pointer, atomic_t or spinlock_t
> in them, but there are of course many more types that you won't
> find in hardware structures.
> 
>>> or if the annotation does not change the layout like
>>> 
>>> struct my_dma_descriptor {
>>>     __le64 address;
>>>     __le64 length;
>>> } __packed; /* does not change layout but makes access slow on some
>>> architectures */
>> 
>> Why is this the case, though? I'd imagine the compiler could figure this
>> out.
> 
> When you annotate the entire structure as __packed without an
> extra __aligned() annotation, the compiler has to assume that the
> structure itself is unaligned as well. On many of the older architectures,
> this will result in accessing the values one byte at a time. Marking
> the structure as "__packed __aligned(8)" instead would be harmless.
> 
> When I have a structure with a few misaligned members, I generally
> prefer to only annotate the members that are not naturally aligned,
> but this approach is not very common.

Searching for specific types in a packed structure would be easy.

Coccinelle could duplicate the structure without the packed and see if any offsets change, using build bug on, but that would be architecture specific so maybe not useful.

Julia



>         Arnd