Re: [PATCH v3] interconnect: avoid memory allocation when 'icc_bw_lock' is held

[Gabor Juhos]

2025. 06. 27. 9:11 keltezéssel, Johan Hovold írta:
> On Thu, Jun 26, 2025 at 05:00:42PM +0200, Gabor Juhos wrote:
>> 2025. 06. 26. 11:30 keltezéssel, Johan Hovold írta:
> 
>>> Note that this could be extended with a
>>> name-allocated flag and an appropriate warning somewhere later if anyone
>>> is worried about drivers failing to use the helper.
>>>
>>> Note that we can't use kfree_const() unconditionally as I initially
>>> intended as apparently some interconnect providers already allocate
>>> names for non-dynamic nodes.
>>
>> Not that I want to worry about anything, but for the sake of completeness I have
>> to note something. Theoretically, freeing the name in icc_node_destroy() could
>> cause the following on IPQ9574 under some circumstances:
>>
>>   [    4.003692] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffff80047e4180 pfn:0x447e4
>>   [    4.008439] flags: 0x0(zone=0)
>>   [    4.017545] raw: 0000000000000000 fffffffec0000448 ffffff803fdbb518 0000000000000000
>>   [    4.020480] raw: ffffff80047e4180 0000000000150000 00000000ffffffff 0000000000000000
>>   [    4.028413] page dumped because: Not a kmalloc allocation
>>
>> It is not a problem of your patch though. The root cause of this is the same
>> as why I saw the lockdep warning on the platform originally. The reason is
>> that the static node ids used by the 'nsscc-ipq9574' driver are within the
>> range of dynamic ids. Nevertheless, I have sent a patch [1] to fix that
>> already.
> 
> Yeah, I saw that patch of yours the other day. Good that you tracked
> that down. I'll probably amend the commit message with a comment about
> why this triggered on IPQ in the first place too.
> 
>> Despite the note above, your proposal looks good to me. Would you like to
>> send it as a formal patch, or shall I do it?
> 
> I can post it in a bit.

Great, just saw the final patch. Thank you!

Regards,
Gabor