All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot@lists.denx.de, Tom Rini <trini@konsulko.com>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH 2/2] efi_loader: Fix warnings on unaligned accesses
Date: Thu, 20 Apr 2023 16:16:40 +0900	[thread overview]
Message-ID: <20230420071640.GB38118@laputa> (raw)
In-Reply-To: <CAC_iWjKd57vzYcaUpdFciLGg+k-Cq2+4eGj4i9Yi8XJ8k+zZMQ@mail.gmail.com>

On Thu, Apr 20, 2023 at 09:35:42AM +0300, Ilias Apalodimas wrote:
> Akashi-san
> 
> On Fri, 7 Apr 2023 at 10:33, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > On Fri, 7 Apr 2023 at 04:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Thu, Apr 06, 2023 at 10:37:07PM +0300, Ilias Apalodimas wrote:
> > > > Tom reports that when building with clang we see this warning:
> > > > field guid within 'struct efi_hii_keyboard_layout' is less aligned than 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being packed, which can lead to unaligned accesses [-Wunaligned-access]
> > > >
> > > > This happens because 'struct efi_hii_keyboard_layout' is defined as
> > > > packed while efi_guid_t is 32bit aligned.
> > >
> > > There are a couple of 'struct' definitions which are *packed*
> > > and contain an 'efi_guid_t' member in efi_api.h.
> > > If 'efi_hii_keyboard_layout' is the only place that causes a clang warning,
> > > we need a more specific explanation to clarify the problem.
> >
> > I assumed that all other definitions are aligned regardless of packed,
> > i.e they are defined right after a u32, u64, 2xu16 etc, but I'll have
> > a closer look
> 
> So I did look closer and my assumption was indeed correct.
> IOW the warning is the only place in the struct definition where
> efi_guid_t happens to be be aligned.

My concern is that we use char[] in one place and efi_guid_t elsewhere.
It sounds arbitrary without any clear explanation.

-Takahiro Akashi


> Tom would you like me to send a v2 on this?
> I think what happens here is that struct efi_hii_keyboard_layout is
> defined as packed, and efi_guid_t is aligned(4).
> So clang is trying to tell us: I will generate safe code for unaligned
> accesses, but one of the struct members requires specific alignment.
> 
> Regards
> /Ilias
> >
> > >
> > > > However the EFI spec describes the EFI_GUID as
> > > > "128-bit buffer containing a unique identifier value.
> > > > Unless otherwise specified aligned on a 64-bit boundary"
> > >
> > > That's right, but this text in this context may sound misleading.
> > > (It doesn't explain why 'efi_guid_t' is 32-bit aligned.)
> >
> > commit 1dd705cf9903 ("efi: use 32-bit alignment for efi_guid_t")
> > explains why, but it's a bit orthogonal to this commit.  In any case
> > I'll include it in v2
> >
> > Thanks
> > /Ilias
> > >
> > > -Takahiro Akashi
> > >
> > > >
> > > > So convert the efi_guid_t -> u8 b[16] here and skip the alignment
> > > > requirements.
> > > >
> > > > Reported-by: Tom Rini <trini@konsulko.com>
> > > > Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > ---
> > > >  include/efi_api.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/efi_api.h b/include/efi_api.h
> > > > index 2fd0221c1c77..b84b577bd7b5 100644
> > > > --- a/include/efi_api.h
> > > > +++ b/include/efi_api.h
> > > > @@ -1170,7 +1170,7 @@ struct efi_key_descriptor {
> > > >
> > > >  struct efi_hii_keyboard_layout {
> > > >       u16 layout_length;
> > > > -     efi_guid_t guid;
> > > > +     u8 guid[16];
> > > >       u32 layout_descriptor_string_offset;
> > > >       u8 descriptor_count;
> > > >       /* struct efi_key_descriptor descriptors[]; follows here */
> > > > --
> > > > 2.39.2
> > > >

  parent reply	other threads:[~2023-04-20  7:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 19:37 [PATCH 1/2] efi_loader: Fix flexible array member definitions Ilias Apalodimas
2023-04-06 19:37 ` [PATCH 2/2] efi_loader: Fix warnings on unaligned accesses Ilias Apalodimas
2023-04-07  1:46   ` AKASHI Takahiro
2023-04-07  2:24     ` Tom Rini
2023-04-07  7:33     ` Ilias Apalodimas
2023-04-20  6:35       ` Ilias Apalodimas
2023-04-20  6:36         ` Ilias Apalodimas
2023-04-20  7:16         ` AKASHI Takahiro [this message]
2023-04-20  7:59           ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230420071640.GB38118@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.