[RFC] netconsole: plan for a safe atomic write

[Breno Leitao <leitao@debian.org>]

Hello,

netconsole is CON_NBCON_ATOMIC_UNSAFE, so write_atomic() only runs at
the very end of panic. There is a desired to have called safe atomic
printing[1].

This is the plan I would like to agree on before posting patches:

1. Now that we have one console per target, use one lock per
   console/target.
   - printk holds the target's device_lock around write_thread(),
     write_atomic() runs under the console ownership, and stopping
     a target takes both. target_list_lock and the cleanup list go away:
     the list changes under dynamic_netconsole_mutex and RTNL, and is
     walked under either.

2. A per-target field to track atomic writes.
   - In that mode, skbs come only from a pool popped without a lock and
     refilled through irq_work.

3. A try-once netpoll transmit, as Jakub outlined [2]:
   - One HARD_TX_TRYLOCK, then busy, with no polling, freeing or
     wakeups, which can deadlock under rq->lock[3].
   - It refuses when this CPU owns the queue (netif_tx_owned()), is in
     the device's NAPI poll (netpoll_owner_active()), or is in NMI on
     PREEMPT_RT.

This does not make ndo_start_xmit() safe, so the flag stays until
drivers can opt in to atomic transmit.

It is still unclear to me whether write_atomic() should depend on the
context (regular NMI/panic): 
 * For regular NMI use the try lock as best effort
 * Ignore the locks only in the final panic flush. (unclear if this is
   an option)

Is this a reasonable plan, or, there are some missing parts I am not
seeing?

Thanks,
--breno

[1] https://lore.kernel.org/all/874ie4y5mw.fsf@jogness.linutronix.de/
[2] https://lore.kernel.org/all/20260617132127.645534d1@kernel.org/
[3] https://lore.kernel.org/all/20260610183621.3915271-1-vlad.wing@gmail.com/