linux-kernel - Re: [PATCH v3] interconnect: avoid memory allocation when 'icc_bw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b960680d-6c5a-4130-b2dd-4ddf1f800430@gmail.com>
Date: Fri, 27 Jun 2025 11:36:26 +0200
From: Gabor Juhos <j4g8y7@...il.com>
To: Johan Hovold <johan@...nel.org>
Cc: Georgi Djakov <djakov@...nel.org>,
 Raviteja Laggyshetty <quic_rlaggysh@...cinc.com>,
 Johan Hovold <johan+linaro@...nel.org>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>, linux-pm@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] interconnect: avoid memory allocation when
 'icc_bw_lock' is held

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