From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@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 16:51:20 -0500 [thread overview]
Message-ID: <CAL_JsqJiKETTMJX3MsEmECE+jtbwYydVSgt1a6poz_L+pPRFTA@mail.gmail.com> (raw)
In-Reply-To: <20201022152253.GJ14816@bill-the-cat>
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_*.
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.
Rob
next prev parent reply other threads:[~2020-10-26 21:51 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 [this message]
[not found] ` <CAL_JsqJiKETTMJX3MsEmECE+jtbwYydVSgt1a6poz_L+pPRFTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-26 22:17 ` Tom Rini
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=CAL_JsqJiKETTMJX3MsEmECE+jtbwYydVSgt1a6poz_L+pPRFTA@mail.gmail.com \
--to=robh-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=trini-OWPKS81ov/FWk0Htik3J/w@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).