All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Date: Mon, 14 Oct 2013 15:00:02 +0200	[thread overview]
Message-ID: <20131014150002.2b1cfe82@lilith> (raw)
In-Reply-To: <yw1x61t03v00.fsf@unicorn.mansr.com>

Hi M?ns,

On Mon, 14 Oct 2013 13:19:27 +0100, M?ns Rullg?rd <mans@mansr.com>
wrote:

> Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
> 
> > Hi M?ns,
> >
> > On Mon, 14 Oct 2013 11:50:42 +0100, M?ns Rullg?rd <mans@mansr.com>
> > wrote:
> >
> >> Piotr Wilczek <p.wilczek@samsung.com> writes:
> >> 
> >> >> -----Original Message-----
> >> >> From: M?ns Rullg?rd [mailto:mans at mansr.com]
> >> >> Sent: Saturday, October 12, 2013 1:29 AM
> >> >> To: Piotr Wilczek
> >> >> Cc: u-boot at lists.denx.de; Tom Rini; Kyungmin Park
> >> >> Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition
> >> >> 
> >> >> Piotr Wilczek <p.wilczek@samsung.com> writes:
> >> >> 
> >> >> > In this patch static variable and memcpy instead of an assignment are
> >> >> > used to avoid unaligned access exception on some ARM platforms.
> >> >> >
> >> >> > Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com>
> >> >> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >> >> > CC: Tom Rini <trini@ti.com>
> >> >> > ---
> >> >> >  disk/part_efi.c |    6 ++++--
> >> >> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >> >> >
> >> >> > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af
> >> >> > 100644
> >> >> > --- a/disk/part_efi.c
> >> >> > +++ b/disk/part_efi.c
> >> >> > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t
> >> >> *dev_desc)
> >> >> >  	p_mbr->signature = MSDOS_MBR_SIGNATURE;
> >> >> >  	p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
> >> >> >  	p_mbr->partition_record[0].start_sect = 1;
> >> >> > -	p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba;
> >> >> > +	memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba,
> >> >> > +	       sizeof(dev_desc->lba));
> >> >> 
> >> >> Why is this assignment problematic?  Note that the compiler may
> >> >> optimise the memcpy() call into a plain assignment including any
> >> >> alignment assumptions it was making in the original code.
> >> >> 
> >> >> The correct fix is either to ensure that pointers are properly aligned
> >> >> or that things are annotated as potentially unaligned, whichever is
> >> >> more appropriate.
> >> >> 
> >> > Problem is that the legacy_mbr structure consists 'le16 unknown'
> >> > field before 'partition_record' filed and the structure is
> >> > packed. As a result the address of 'partition_record' filed is
> >> > halfword aligned. The compiler uses str/ldr instructions (address
> >> > must be 4-byte aligned) to copy u32 'lba' data thus causing
> >> > unaligned access exception.
> >> 
> >> If the struct has __attribute__((packed)), gcc should do the right thing
> >> already.  Note that on ARMv6 and later ldr/str support unaligned
> >> addresses unless this is explicitly disabled in the system control
> >> register.  If you do this, you _MUST_ compile with -mno-unaligned-access.
> >> Otherwise you will get problems.
> >
> > Please do not advise using native unaligned accesses on code that is
> > not strictly used by ARMv6+ architectures: the present code, for
> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus,
> > should never assume ability to perform unaligned accesses natively.
> 
> I'm advising no such thing.  I said two things:
> 
> 1.  Declaring a struct with the 'packed' attribute makes gcc
>     automatically generate correct code for all targets.  _IF_ the
>     selected target supports unaligned ldr/str, these might get used.
> 
> 2.  If your target is ARMv6 or later _AND_ you enable strict alignment
>     checking in the system control register, you _MUST_ build with the
>     -mno-unaligned-access flag.

Then I apologize; I had read "Note that on ARMv6 and later ldr/str
support unaligned addresses unless this is explicitly disabled in
the system control register" as a suggestion to use that capability.

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-10-14 13:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 13:31 [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition Piotr Wilczek
2013-10-11 16:00 ` Albert ARIBAUD
2013-10-11 23:28 ` Måns Rullgård
2013-10-14  8:30   ` Piotr Wilczek
2013-10-14 10:50     ` Måns Rullgård
2013-10-14 11:46       ` Albert ARIBAUD
2013-10-14 12:19         ` Måns Rullgård
2013-10-14 13:00           ` Albert ARIBAUD [this message]
2013-10-14 13:05             ` Måns Rullgård
2013-10-14 13:48               ` Albert ARIBAUD
2013-10-14 14:09                 ` Måns Rullgård
2013-10-14 15:18                   ` Albert ARIBAUD
2013-10-14 15:59                     ` Måns Rullgård
2013-10-14 17:26                       ` Albert ARIBAUD
2013-10-15 15:23                         ` Måns Rullgård
2013-10-15 16:21                           ` Albert ARIBAUD
2013-10-15 16:29                             ` Måns Rullgård
2013-10-15 17:07                               ` Albert ARIBAUD
2013-10-14 13:49               ` Piotr Wilczek
2013-10-14 14:22                 ` Albert ARIBAUD
2014-01-28 12:46 ` [U-Boot] [PATCH V2] " Piotr Wilczek
2014-01-29 21:48   ` Tom Rini
2014-02-19 14:56   ` Hector Palacios
2014-02-19 15:03     ` Tom Rini
2014-02-19 15:23       ` Tom Rini
2014-02-24 15:56         ` Lukasz Majewski
2014-02-24 16:23           ` Tom Rini

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=20131014150002.2b1cfe82@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.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.