From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: David Laight <David.Laight@ACULAB.COM>
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:22:53 +0100 [thread overview]
Message-ID: <20210713112253.GH22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <012ccfea2a564274bd9d2e1cfc130873@AcuMS.aculab.com>
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.
> 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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: David Laight <David.Laight@ACULAB.COM>
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:22:53 +0100 [thread overview]
Message-ID: <20210713112253.GH22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <012ccfea2a564274bd9d2e1cfc130873@AcuMS.aculab.com>
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.
> 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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-13 11:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 23:19 [PATCH] divide by 3*sizeof(u32) when computing array_size Salah Triki
2021-07-12 23:19 ` Salah Triki
2021-07-13 6:02 ` Philipp Hahn
2021-07-13 6:02 ` Philipp Hahn
2021-07-13 6:30 ` Uwe Kleine-König
2021-07-13 6:30 ` Uwe Kleine-König
2021-07-13 9:07 ` Uwe Kleine-König
2021-07-13 9:07 ` Uwe Kleine-König
2021-07-13 9:19 ` Russell King (Oracle)
2021-07-13 9:19 ` Russell King (Oracle)
2021-07-13 11:07 ` David Laight
2021-07-13 11:07 ` David Laight
2021-07-13 11:22 ` Russell King (Oracle) [this message]
2021-07-13 11:22 ` Russell King (Oracle)
2021-07-13 12:20 ` David Laight
2021-07-13 12:20 ` David Laight
2021-07-13 12:35 ` Russell King (Oracle)
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=20210713112253.GH22278@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=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=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 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.