From: Leonard Crestez <leonard.crestez@nxp.com>
To: Stephen Boyd <sboyd@kernel.org>, Shawn Guo <shawnguo@kernel.org>
Cc: Aisheng Dong <aisheng.dong@nxp.com>,
Fabio Estevam <fabio.estevam@nxp.com>,
Michael Turquette <mturquette@baylibre.com>,
Stefan Agner <stefan@agner.ch>,
Linus Walleij <linus.walleij@linaro.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Anson Huang <anson.huang@nxp.com>, Abel Vesa <abel.vesa@nxp.com>,
Franck Lenormand <franck.lenormand@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
dl-linux-imx <linux-imx@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>
Subject: Re: [PATCH v2 1/8] clk: imx: Align imx sc clock msg structs to 4
Date: Tue, 25 Feb 2020 19:52:11 +0000 [thread overview]
Message-ID: <VI1PR04MB70233A098DC4A2A82B114E93EEED0@VI1PR04MB7023.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 158264951569.54955.16797064769391310232@swboyd.mtv.corp.google.com
On 25.02.2020 18:52, Stephen Boyd wrote:
> Quoting Leonard Crestez (2020-02-20 08:29:32)
>> The imx SC api strongly assumes that messages are composed out of
>> 4-bytes words but some of our message structs have odd sizeofs.
>>
>> This produces many oopses with CONFIG_KASAN=y.
>>
>> Fix by marking with __aligned(4).
>>
>> Fixes: fe37b4820417 ("clk: imx: add scu clock common part")
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> ---
>> drivers/clk/imx/clk-scu.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
>> index fbef740704d0..3c5c42d8833e 100644
>> --- a/drivers/clk/imx/clk-scu.c
>> +++ b/drivers/clk/imx/clk-scu.c
>> @@ -41,16 +41,16 @@ struct clk_scu {
>> struct imx_sc_msg_req_set_clock_rate {
>> struct imx_sc_rpc_msg hdr;
>> __le32 rate;
>> __le16 resource;
>> u8 clk;
>> -} __packed;
>> +} __packed __aligned(4);
>
> Sorry, this still doesn't make sense to me. Having __aligned(4) means
> that the struct is placed on the stack at some alignment, great, but it
> still has __packed so the sizeof this struct is some odd number like 11.
> If this struct is the last element on the stack it will end at some
> unaligned address and the mailbox code will read a few bytes beyond the
> end of the stack.
I checked again and marking the struct with __aligned(4) makes it have
sizeof == 12 as intended. It was 11 before.
static_assert(sizeof(struct imx_sc_msg_req_set_clock_rate) == 12);
After reading through your email and gcc docs again I'm not sure if this
portable/reliable this is but as far as I understand "sizeof" needs to
account for alignment. Or is this just an accident with my compiler?
Marking a structure both __packed and __aligned(4) means that __packed
only affects internal struct member layout but sizeof is still rounded
up to a multiple of 4:
struct test {
u8 a;
u16 b;
} __packed __aligned(4);
static_assert(sizeof(struct test) == 4);
static_assert(offsetof(struct test, a) == 0);
static_assert(offsetof(struct test, b) == 1);
This test is not realistic because I don't think SCU messages have any
such oddly-aligned members.
>
> I see that the calling code puts 3 as the 'size' for this struct in
> clk_scu_set_rate().
>
> hdr->size = 3;
>
> That seems to say that the struct is 3 words long, or 12 bytes. Then we
> call imx_scu_call_rpc(), passing the pointer to this struct on the stack
> and that eventually gets into imx_scu_ipc_write() calling
> mbox_send_message() with u32 pointers.
>
> for (i = 0; i < hdr->size; i++) {
> sc_chan = &sc_ipc->chans[i % 4];
> ret = mbox_send_message(sc_chan->ch, &data[i]);
>
> So we've taken the 11 byte struct (data in this case) and casted it to a
> u32 array with 3 elements, which is bad. This is what kasan is warning
> about. Adding aligned sometimes fixes it because the compiler will place
> the next stack variable at the naturally aligned location and thus we
> get the one byte padding but I don't see how that works when it's the
> last stack element. The stack will end at some unaligned address.
>
> The better solution would be to drop __aligned(4) and make a union of
> the struct with whatever size number of words the message is or do a
> copy of the struct into a u32 array that is passed to
> imx_scu_call_rpc().
>
> For example:
>
> struct imx_sc_msg_req_set_clock_rate {
> union {
> struct packed_message {
> struct imx_sc_rpc_msg hdr;
> __le32 rate;
> __le16 resource;
> u8 clk;
> } __packed;
> u32 data[3];
> };
> };
>
> If the union approach was used then each time imx_scu_call_rpc() is
> called we can simply pass the 'data' member and make the second argument
> 'msg' strongly typed to be a u32 pointer. kasan should be happy too.
>
next prev parent reply other threads:[~2020-02-25 19:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 16:29 [PATCH v2 0/8] firmware: imx: Align imx SC msg structs to 4 Leonard Crestez
2020-02-20 16:29 ` [PATCH v2 1/8] clk: imx: Align imx sc clock " Leonard Crestez
2020-02-24 7:22 ` Shawn Guo
2020-03-16 0:25 ` Shawn Guo
2020-02-25 16:51 ` Stephen Boyd
2020-02-25 19:52 ` Leonard Crestez [this message]
2020-03-16 8:52 ` Aisheng Dong
2020-02-20 16:29 ` [PATCH v2 2/8] clk: imx: Align imx sc clock parent " Leonard Crestez
2020-02-24 7:23 ` Shawn Guo
2020-02-20 16:29 ` [PATCH v2 3/8] firmware: imx: misc: Align imx sc " Leonard Crestez
2020-02-24 7:28 ` Shawn Guo
2020-02-20 16:29 ` [PATCH v2 4/8] firmware: imx: scu-pd: " Leonard Crestez
2020-02-24 7:28 ` Shawn Guo
2020-02-20 16:29 ` [PATCH v2 5/8] firmware: imx: Align imx_sc_msg_req_cpu_start " Leonard Crestez
2020-02-24 7:28 ` Shawn Guo
2020-02-20 16:29 ` [PATCH v2 6/8] pinctrl: imx: scu: Align imx sc msg structs " Leonard Crestez
2020-02-21 15:34 ` Linus Walleij
2020-02-20 16:29 ` [PATCH v2 7/8] rtc: imx-sc: " Leonard Crestez
2020-03-03 11:02 ` Alexandre Belloni
2020-02-20 16:29 ` [PATCH v2 8/8] soc: imx-scu: " Leonard Crestez
2020-02-24 7:30 ` Shawn Guo
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=VI1PR04MB70233A098DC4A2A82B114E93EEED0@VI1PR04MB7023.eurprd04.prod.outlook.com \
--to=leonard.crestez@nxp.com \
--cc=a.zummo@towertech.it \
--cc=abel.vesa@nxp.com \
--cc=aisheng.dong@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=anson.huang@nxp.com \
--cc=fabio.estevam@nxp.com \
--cc=franck.lenormand@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-rtc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
--cc=stefan@agner.ch \
/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 NNTP newsgroup(s).