[PATCH v4] media: verisilicon: Fix kernel panic due to __initconst misuse

[Nicolas Dufresne]

Le jeudi 12 mars 2026 à 18:34 +0100, Francesco Dolcini a écrit :
> Hello,
> 
> On Fri, Mar 06, 2026 at 11:10:57AM +0800, ming.qian at oss.nxp.com wrote:
> > From: Ming Qian <ming.qian at oss.nxp.com>
> > 
> > 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 <krzysztof.kozlowski at oss.qualcomm.com>
> > Closes: https://lore.kernel.org/all/68ef934f-baa0-4bf6-93d8-834bbc441e66@kernel.org/
> > Reported-by: Franz Schnyder <franz.schnyder at toradex.com>
> > Closes: https://lore.kernel.org/all/n3qmcb62tepxltoskpf7ws6yiirc2so62ia23b42rj3wlmpl67@rvkbuirx7kkp/
> > Fixes: e0203ddf9af7 ("media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC")
> > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
> > Suggested-by: Marco Felsch <m.felsch at pengutronix.de>
> > Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>
> > Signed-off-by: Ming Qian <ming.qian at oss.nxp.com>
> 
> 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.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260316/3026538d/attachment.sig>