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

[Johan Hovold <johan@kernel.org>]

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.

Johan