Re: media: ipu-bridge: lifetime of retained software-node properties

["D. Manresa" <dmanresa@gmail.com>]

On Mon, Oct 26, 2026 at 11:11:06AM +0000, Fernando Rimoli wrote:
> As far as I can see, with those two gone nothing in the graph points
> into the module any more and every other name and value is already a
> per-sensor copy.

I checked that instead of just agreeing with it, since Ruslan and Sergey
are both about to add properties and it is a bad thing to get wrong. It
holds, with one trap worth recording.

Against media/next with v5 applied, in ipu-bridge.c:

- every registered node's .name is a per-sensor or per-bridge char
  array: sensor->name, sensor->ivsc_name, sensor->node_names.*, and
  bridge->ipu_node_name for the IPU HID node itself;
- every property name comes from sensor->prop_names, a struct
  ipu_property_names of char arrays copied per sensor;
- every property value is an inline scalar, bridge->data_lanes,
  sensor->link_freqs (what 1/2 changes) or one of the sensor->*_ref
  arrays;
- there is no PROPERTY_ENTRY_STRING anywhere, so no property holds a
  string pointer as a value;
- .properties and .parent all point inside struct ipu_sensor or at
  bridge->ipu_hid_node.

All of that lives in the struct ipu_bridge that ipu_bridge_init()
allocates and then deliberately never frees: kfree(bridge) appears only
on the error paths, and there is no module_exit() or remove hook. So the
precise statement is not that nothing points into the module, but that
everything points into a heap allocation that outlives it. That is also
the answer to where a new name or value should go.

The trap: sensor->vcm_type still points into ipu_vcm_types[], which is
module rodata, and it survives in the retained struct. It is not a bug
today, because it is only read during init, and the one thing that runs
later -- ipu_bridge_instantiate_vcm() -- takes the VCM type from "%pfwP"
of the fwnode, that is from sensor->node_names.vcm, not from vcm_type.
But it is a dangling pointer sitting in a struct that outlives the
module, and the next person to read it from a rebind path will not
expect that. Either a comment or copying it like everything else would
close it.

If it helps: I have a Surface Pro 7+ (IPU6 Tiger Lake, three sensors on
the bridge) here for a few more days and can exercise the unload and the
PCI remove/rescan paths on it, which is where all of this actually
bites. Ask while it is still here.

D. Manresa

(Written with AI assistance, directed and reviewed by me. Resent as
plain text: the first copy was rejected by the list for carrying an HTML
part, so it reached the Cc list but never the archive. Apologies to
those getting it twice.)