On 23.05.2023 11:47, Dan Carpenter wrote:
> On Tue, May 23, 2023 at 10:31:27AM +0200, Konrad Dybcio wrote:
>>
>>
>> On 23.05.2023 10:11, Dan Carpenter wrote:
>>> This was allocating "sizeof(qp->intf_clks)" which is the size of a
>>> pointer instead of "sizeof(*qp->intf_clks)" which is the size of the
>>> struct (8 bytes vs 16 bytes on a 64bit system).
>>>
>>> Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
>>> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
>> Whoops. Guess I was just really really lucky that nothing blew up for me.
>>
>> Thanks.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
>
> Hold up. Wait... Let's not apply this. The bug is more severe than I
> saw initially. It should be:
>
> qp->intf_clks = devm_kcalloc(dev, cd_num, sizeof(*qp->intf_clks),
> GFP_KERNEL);
>
> Did we only test with cd_num set to zero?
No, I also had buses using cd_num >= 1..
Interestingly enough the clocks with the higher indices *did*
in fact get enabled (the platform would otherwise crash on set_bw
during sync_state if they didn't), at least in the
probe (-> allocate) -> sync_state
path.
But there's not a whole lot of allocations in between, so perhaps
it must have been luck as well..
TYSM for catching this..
Konrad
>
> regards,
> dan carpenter
>
>
