Thread (10 messages) 10 messages, 7 authors, 2026-03-17

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help