From: David Laight <David.Laight@ACULAB.COM>
To: 'Russell King' <linux@armlinux.org.uk>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Salah Triki" <salah.triki@gmail.com>,
"fabrice.gasnier@foss.st.com" <fabrice.gasnier@foss.st.com>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
"alexandre.torgue@foss.st.com" <alexandre.torgue@foss.st.com>,
"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
"linux-stm32@st-md-mailman.stormreply.com"
<linux-stm32@st-md-mailman.stormreply.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] divide by 3*sizeof(u32) when computing array_size
Date: Tue, 13 Jul 2021 12:20:26 +0000 [thread overview]
Message-ID: <2f725f0be09349308bf7d9a24399d516@AcuMS.aculab.com> (raw)
In-Reply-To: <20210713112253.GH22278@shell.armlinux.org.uk>
From: Russell King
> Sent: 13 July 2021 12:23
>
> On Tue, Jul 13, 2021 at 11:07:00AM +0000, David Laight wrote:
> > From: Russell King
> > > Sent: 13 July 2021 10:20
> > ....
> > > I would also note that the code relies on there being no padding in
> > > struct stm32_breakinput - it should be noted that a strict
> > > interpretation of the C standard allows padding to be added anywhere
> > > to a structure - at the start, end or between members.
> >
> > I'm pretty certain I remember that padding before the first member
> > isn't allowed.
>
> You may be right there.
>
> > In any case the kernel generally assumes there is no extra padding.
> > (eg for structures that map hardware registers.)
>
> That's incorrect. Places where we care either generally end up with
> __packed or are carefully layed out to ensure members are naturally
> aligned to reduce the likelyhood of it. 32-bit OABI ARM has been
> particularly "fun" in this respect.
I did say 'extra padding'.
Ensuring everything is naturally aligned is best - shame the standards
bodies don't do that - just look at the SCTP socket options.
Adding __packed is right sometimes, but it isn't without cost
and is probably wrong for anything hardware related.
Definitely useful on structure members to remove the padding
before that specific member (eg for 64bit in x86 compat code).
But marking a structure __packed is usually wrong (or bad).
> > For big structures it is worth adding a compile-time check of
> > the structure size - but not really for three u32.
>
> Sorry, structure size has absolutely nothing to do with whether it's
> a good idea to have a compile-time check. The deciding factor is
> whether the code relies on some property such as it being a certain
> size. Such as in this exact case. If you grep for "BUILD_BUG_ON.*sizeof"
> in fs/ for example, this illustrates the point rather well.
I'd not bother if the size is obviously going to be correct.
I did get some odd bugs a few years ago from a compiler that aligned
all structures on 4-byte boundaries.
I had to change a structure of two u16 into an array :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-07-13 12:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 23:19 Salah Triki
2021-07-13 6:02 ` Philipp Hahn
2021-07-13 6:30 ` Uwe Kleine-König
2021-07-13 9:07 ` Uwe Kleine-König
2021-07-13 9:19 ` Russell King (Oracle)
2021-07-13 11:07 ` David Laight
2021-07-13 11:22 ` Russell King (Oracle)
2021-07-13 12:20 ` David Laight [this message]
2021-07-13 12:35 ` Russell King (Oracle)
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=2f725f0be09349308bf7d9a24399d516@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=alexandre.torgue@foss.st.com \
--cc=fabrice.gasnier@foss.st.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=salah.triki@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®