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: <aF5EPhd5smrmB38Q@hovoldconsulting.com>
Date: Fri, 27 Jun 2025 09:11:58 +0200
From: Johan Hovold <johan@...nel.org>
To: Gabor Juhos <j4g8y7@...il.com>
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

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