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

[Ard Biesheuvel]

On Thu, 2 Jun 2022 at 14:12, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Thu, Jun 2, 2022 at 1:21 PM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
> > On 2022/06/02 16:38, Arnd Bergmann wrote:
> > >> But let's cc the tomoyo and chelsio people.
> > >
> > > I think both of them work because the structures are always
> > > embedded inside of larger structures that have at least word
> > > alignment. This is the thing I was looking for, and the
> > > __packed attribute was added in error, most likely copied
> > > from somewhere else.
> >
> > The __packed in "struct tomoyo_shared_acl_head" is to embed next
> > naturally-aligned member of a larger struct into the bytes that
> > would have been wasted if __packed is not specified. For example,
> >
> > struct tomoyo_shared_acl_head {
> >         struct list_head list;
> >         atomic_t users;
> > } __packed;
> >
> > struct tomoyo_condition {
> >         struct tomoyo_shared_acl_head head;
> >         u32 size; /* Memory size allocated for this entry. */
> >         (...snipped...)
> > };
> >
> > saves 4 bytes on 64 bits build.
> >
> > If the next naturally-aligned member of a larger struct is larger than
> > the bytes that was saved by __packed, the saved bytes will be unused.
>
> Ok, got it. I think as gcc should still be able to always figure out the
> alignment when accessing the atomic, without ever falling back
> to byte access on an atomic_get() or atomic_set().
>
> To be on the safe side, I would still either move the __packed attribute
> to the 'list' member, or make the structure '__aligned(4)'.
>

The tomoyo code generates lots of byte size accesses when built for
ARMv5, but interestingly, the atomic_t accesses are emitted normally,
probably due to the fact that the C api (atomic_read, atomic_set, etc)
takes atomic_t pointers, and so GCC assumes natural alignment, even
when inlining. But ordinary accesses of multi-byte fields in the
structs in question are emitted as sequences of LDRB instructions.

I understand the reason for these annotations, but I think we should
drop them anyway, and just let the compiler organize the structs.