Question: prestera: clarify event handler RCU-list contract

[Runyu Xiao]

Hi Prestera maintainers,

This question comes from a candidate found by our static analysis tool
and then manually reviewed against the current tree. The audit used
CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
for maintainer guidance because the source-level review did not prove
a use-after-free.

A CONFIG_PROVE_RCU_LIST audit flags the shared event-handler lookup
helper:

  drivers/net/ethernet/marvell/prestera/prestera_hw.c:923 __find_event_handler()

The receive-side paths use prestera_find_event_handler(), which wraps
the helper in rcu_read_lock(), copies the handler record, and drops RCU
before invoking the callback.

The registration paths call __find_event_handler() directly:

  drivers/net/ethernet/marvell/prestera/prestera_hw.c:2255 prestera_hw_event_handler_register()
  drivers/net/ethernet/marvell/prestera/prestera_hw.c:2280 prestera_hw_event_handler_unregister()

Registration adds entries with list_add_rcu().  Unregistration removes
entries with list_del_rcu() and frees them with kfree_rcu().  The call
sites look init/fini-style, and I am not claiming a use-after-free here.
The question is only how the non-receive-side lookup contract is meant
to be expressed.

Would you prefer one of these directions?

  1. split the helper into an RCU-reader lookup and a registration-time
     lookup;

  2. wrap the direct register/unregister lookups in a local RCU read-side
     section;

  3. add an explicit event-handler registration lock if concurrent
     register/unregister is possible;

  4. document that handler registration is init/fini ordered and leave
     the direct helper calls unchanged.

I am intentionally sending this as a maintainer question rather than a
patch because the right shape depends on the intended registration and
teardown model.

Thanks.