Re: [PATCH v5 0/2] media: ipu-bridge: survive module unload and reuse the software nodes on rebind

[Sergey Lebedev]

Hi Dario,

You asked for a run with KASAN on IPU hardware. Here is one, with a
result that is partly about my own patch.

Setup: a Surface Pro 11 (Lunar Lake, IPU7 8086:645d, run by
intel-ipu6), media next d7e7bca7169 with my VD55G0 v1 series, generic
inline KASAN with KASAN_VMALLOC, which KASAN needs to see module memory
at all, and lockdep. KASAN reports only once per boot, so each variant
had a boot of its own. The sequence: load the IPU stack, capture, unload
intel_ipu6_isys, intel_ipu6 and ipu_bridge, then unbind and bind the
VD55G0 with the bridge gone.

  variant                                   bind after the unload
  my v1 series as posted                    froze, 2 of 2 boots
  + your v5                                 froze, 1 of 1
  + your v5 + my 4/4 fixed (st,leds name    clean
    and GPIOs in the bridge's structs)

The freezes were total. The persistent journal stops before the bind,
with no KASAN report and no Oops, and kdump did not fire even with
panic_on_oops, the soft and hard lockup panics and hung_task_panic
armed; only the power button brought the machine back. With the bridge
still loaded, the same rebind is clean. So on this machine the dangling
pointer that freezes it is my st,leds, which Fernando pointed out on
25/10. Every run without that fix froze at the first read, so I cannot
tell what link-frequencies alone would have done. KASAN reported nothing
even where it should have, so the evidence for v5 below is that what
froze before no longer does, not KASAN's silence.

With v5 and the fix, the run went on, all clean (no KASAN, lockdep or
Oops lines, debug_locks still 1), with a capture of 10 of 10 frames
after each step:

- the rebind above;
- a reload of the stack;
- four PCI remove/rescan cycles of the IPU, each logging "Reusing the
  previously registered software nodes", none hitting a duplicate
  INT343E node, and the IPU7 back each time without a cold boot;
- one remove -> unload -> rescan -> reload cycle, as in your cover
  letter.

Only the VD55G0 was bound on that kernel (the stock OV13858 driver fails
probe on this machine without a patch of mine), so that is the sensor
the run covers. The only WARNING was the known one at
ipu6-isys-queue.c:203, once per stream start, in every variant.

So both patches ran here and held. The failure they guard against is
not a quiet stale read: for an st,leds-style property, it is a machine
that has to be power-cycled. My v2 4/4 keeps st,leds in the bridge's
structs, as your 1/2 does for lens-focus and link-frequencies.

Tested-by: Sergey Lebedev <lsa.uz@xxxxx> # Surface Pro 11, IPU7, KASAN

Sergey