From: Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: David Gibson
<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>,
Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Devicetree Compiler
<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Size growth?
Date: Mon, 26 Oct 2020 18:17:27 -0400 [thread overview]
Message-ID: <20201026221727.GY14816@bill-the-cat> (raw)
In-Reply-To: <CAL_JsqJiKETTMJX3MsEmECE+jtbwYydVSgt1a6poz_L+pPRFTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4266 bytes --]
On Mon, Oct 26, 2020 at 04:51:20PM -0500, Rob Herring wrote:
> On Thu, Oct 22, 2020 at 10:23 AM Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> > On Fri, Oct 23, 2020 at 01:58:04AM +1100, David Gibson wrote:
> > > On Thu, Oct 22, 2020 at 08:32:54AM -0400, Tom Rini wrote:
> > > > On Thu, Oct 22, 2020 at 03:00:13PM +1100, David Gibson wrote:
> > > > > On Wed, Oct 21, 2020 at 06:49:14PM -0400, Tom Rini wrote:
>
> [...]
>
> > > > > > But what does all of this _mean_ ? I kinda think I have an answer now.
> > > > > > One of the things that sticks out is 6dcb8ba408ec adds a lot and
> > > > > > 11738cf01f15 reduces it just a little.
> > > > >
> > > > > Ah, that's a tricky one. If we don't handle unaligned accesses we
> > > > > instead get intermittent bug reports where it just crashes.
> > > >
> > > > We really need to talk about that then. There was a problem of people
> > > > turning off the sanity check for making sure the entire device tree was
> > > > aligned and then having everything crash.
> > >
> > > Ok... I'm not really sure where you're going with that thought.
> >
> > In my reading of the mailing list history of how this issue came up,
> > it was someone was booting a dragonboard or something, and they (or
> > rather, the board maintainer set by default) the flag to use the device
> > tree wherever it is in memory and NOT to relocate it to a properly
> > aligned address. This in turn lead to the kernel getting an unaligned
> > device tree and everything crashing. The "I know what I'm doing" flag
> > was set, violated the documented requirements for device trees need to
> > reside in memory and everything blew up.
> >
> > After that it was noticed that there could be some internal
> > mis-alignment and if you tried those accesses on a CPU that doesn't
> > support doing those reads easily there could be problems, but that's not
> > a common at all case (as noted by it not having been seen in practice).
>
> Nor a problem on many environments to begin with. More below...
>
> > > > > I suppose we could add an ASSUME_ALIGNED_ACCESS flag, and it will just
> > > > > break for either an unaligned dtb (unlikely) or if you attempt to load
> > > > > an unaligned value from a property (more likely, but don't add the
> > > > > flag if you're not sure you don't need it).
> > > >
> > > > So long as it's abstracted in such a way that we don't grow the size of
> > > > everything again, yes, that is the right way forward I think.
> > >
> > > All the ASSUME flags should be resolved at compile time (at least with
> > > normal optimization levels enabled in the compiler), so testing for
> > > those shouldn't increase size at all. If they do, something is wrong.
> >
> > I'm saying that how ever this new ASSUME flag is done, it needs to be
> > done in such a way the compiler really will be smart about it. So
> > something like making a new function that does fdt64_ld() if we aren't
> > ASSUME_ALIGNED_ACCESS and fdt64_to_cpu() if we are
> > ASSUME_ALIGNED_ACCESS.
>
> Ah, unaligned accesses again... To summarize, both performance and
> size suffer with not doing unaligned accesses.
>
> Why not a HAS_UNALIGNED_ACCESS flag instead (or the inverse) that will
> do unaligned accesses? That would be more aligned with what the system
> can support rather than sanity checking associated with ASSUME_*.
I leave this up to the dtc folks. With my U-Boot hat on, we'll be
defaulting to "unaligned is fine" for everyone.
> To repeat from last time, everything ARMv6 and up can do unaligned
> accesses if enabled. That's the vast majority of Arm systems that
> people care about. Whether that's enabled or not is up to how SCTLR.A
> is configured. Last I checked, u-boot clears this. Don't know about
> SPL case though.
I think it's something close to never do we ever have things configured
such that truly unaligned access is a problem. The historical problem
wasn't even that something wasn't at all aligned, it was 4-byte aligned
when the requirement was 8-byte aligned and everything failed. Only
later were totally unaligned parts of the tree found and that's still
not a problem for how U-Boot uses things.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2020-10-26 22:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 19:36 Size growth? Tom Rini
2020-10-16 21:46 ` Simon Glass
[not found] ` <CAPnjgZ3jPciWmoVpuoYb9KC2h3eCevZsq+1BzefCOCAFCDoseQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-19 1:42 ` David Gibson
[not found] ` <20201019014213.GA11625-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-19 12:37 ` Tom Rini
2020-10-20 2:09 ` David Gibson
[not found] ` <20201020020907.GA64103-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-21 22:49 ` Tom Rini
2020-10-22 4:00 ` David Gibson
[not found] ` <20201022040013.GB1821515-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-22 12:32 ` Tom Rini
2020-10-22 14:58 ` David Gibson
[not found] ` <20201022145804.GI1821515-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-22 15:22 ` Tom Rini
2020-10-26 21:51 ` Rob Herring
[not found] ` <CAL_JsqJiKETTMJX3MsEmECE+jtbwYydVSgt1a6poz_L+pPRFTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-26 22:17 ` Tom Rini [this message]
2020-10-27 15:57 ` André Przywara
[not found] ` <a14daf09-4d97-052f-5071-09e67ccb925e-5wv7dgnIgG8@public.gmane.org>
2020-10-27 19:55 ` Rob Herring
[not found] ` <CAL_JsqK_fC346UnCmXMJxKHCM6=eFBF_kmGt_fBdvwPXbPRkvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-28 4:26 ` David Gibson
[not found] ` <20201028042601.GA5604-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-28 12:05 ` Tom Rini
2020-10-29 2:55 ` David Gibson
[not found] ` <20201029025503.GI5604-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-29 15:06 ` Tom Rini
2020-10-29 15:48 ` Rob Herring
[not found] ` <CAL_JsqJUixnyZx-tu9EV8YZ-gSDE7i1jvMddnNZZWFzezaHftw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-29 16:04 ` Tom Rini
2020-10-29 18:08 ` Rob Herring
[not found] ` <CAL_JsqJTTJAoTYwxDn3i0KETMXLyGg3WXzxN3-OdRLx=R96a-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-29 20:21 ` Tom Rini
2020-11-02 2:06 ` David Gibson
2020-10-28 17:49 ` Rob Herring
[not found] ` <CAL_JsqJPrnjKjdmvyY2NOay0YrYc20Tr3OSr0yjq+9HjCN+anA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-29 3:02 ` David Gibson
[not found] ` <20201029030247.GJ5604-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-29 15:04 ` Tom Rini
2020-10-29 19:56 ` David Gibson
[not found] ` <20201029195658.GK5604-l+x2Y8Cxqc4e6aEkudXLsA@public.gmane.org>
2020-10-29 20:26 ` 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=20201026221727.GY14816@bill-the-cat \
--to=trini-owpks81ov/fwk0htik3j/w@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).