RE: [PATCH v2 1/8] clk: imx: Align imx sc clock msg structs to 4

[Aisheng Dong <aisheng.dong@xxxxxxx>]

> From: Stephen Boyd <sboyd@xxxxxxxxxx>
> Sent: Wednesday, February 26, 2020 12:52 AM 
> 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@xxxxxxx>
> > ---
> >  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.

Hi Leonard,

Can you construct this case to see if we can reproduce the issue as pointed by Stephen?

Regards
Aisheng

> 
> 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.