Re: [PATCH v4] media: verisilicon: Fix kernel panic due to __initconst misuse
From: Francesco Dolcini <francesco@dolcini.it>
Date: 2026-03-16 16:01:40
Also in:
imx, linux-devicetree, linux-media, linux-pm, lkml, regressions
On Mon, Mar 16, 2026 at 04:56:09PM +0100, Thorsten Leemhuis wrote:
On 3/16/26 16:25, Nicolas Dufresne wrote:quoted
Le jeudi 12 mars 2026 à 18:34 +0100, Francesco Dolcini a écrit :quoted
On Fri, Mar 06, 2026 at 11:10:57AM +0800, ming.qian@oss.nxp.com wrote:quoted
From: Ming Qian <redacted> Fix a kernel panic when probing the driver as a module: Unable to handle kernel paging request at virtual address ffffd9c18eb05000 of_find_matching_node_and_match+0x5c/0x1a0 hantro_probe+0x2f4/0x7d0 [hantro_vpu] The imx8mq_vpu_shared_resources array is referenced by variant structures through their shared_devices field. When built as a module, __initconst causes this data to be freed after module init, but it's later accessed during probe, causing a page fault. The imx8mq_vpu_shared_resources is referenced from non-init code, so keeping __initconst or __initconst_or_module here is wrong. Drop the __initconst annotation and let it live in the normal .rodata section. A bug of __initconst called from regular non-init probe code leading to bugs during probe deferrals or during unbind-bind cycles. Reported-by: Krzysztof Kozlowski <redacted> Closes: https://lore.kernel.org/all/68ef934f-baa0-4bf6-93d8-834bbc441e66@kernel.org/ (local) Reported-by: Franz Schnyder <redacted> Closes: https://lore.kernel.org/all/n3qmcb62tepxltoskpf7ws6yiirc2so62ia23b42rj3wlmpl67@rvkbuirx7kkp/ (local) Fixes: e0203ddf9af7 ("media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC") Suggested-by: Krzysztof Kozlowski <redacted> Suggested-by: Marco Felsch <redacted> Reviewed-by: Marco Felsch <redacted> Signed-off-by: Ming Qian <redacted>What's the plan to merge this? It fixes a quite severe regression, a boot failure.To be decided this week. The commit message does not say if it was released, or came in RCs (and I didn't check myself yet). I'd say, if its the first one, it will go through next and backports, otherwise its is really tight to get that into the RC series, but serious enough. Please fill the gap if you have time, and I'll handle it later, probably tomorrow.Well, FYI: the culprit according to the fixes tag quoted above is e0203ddf9af7c8 ("media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC") [v7.0-rc1, v6.19.6 (286d629d10640b)]. Given that this was * reported 11 days ago * reported at least two times * made it into a stable series it is something that Linus would like to see fixed by now in mainline afaics, as ""the rule of thumb should generally be "within a week", preferably before the next rc."": https://www.kernel.org/doc/html/next/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed If that fix is too dangerous a revert is of course an option, too. BTW, given that the culprit made it to a stable series, it would be a wise to add a stable tag to ensure it's backported (it otherweise might be silent dropped and/or applying might be deferred).
Absolutely ... the tag here should help b4 Cc: stable@vger.kernel.org Francesco