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

[Leonard Crestez <leonard.crestez@xxxxxxx>]

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

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