On 3/18/2026 12:24 AM, Sebastian Andrzej Siewior wrote:
On 2026-03-17 12:30:39 [-0700], Tantilov, Emil S wrote:
What would break if you make that lock a spinlock_t?
Right. Scope and risk - these fixes are specifically for the async
handler and I did not want to touch the global locking that will
impact the entire VC handling. We do have series in flight for -next
that refactor that code, while moving it to libie:
https://lore.kernel.org/netdev/[email protected]/
Now I understood. You fiddle with the completion's lock. That is
something that should not have been done.
... that also remove the raw spinlock. With that being said, I can look
into converting the lock to spinlock_t if that is the preferred approach.
The preferred approach is that, if you pick raw_spinlock_t for locking,
you are aware of all the consequences and you have a solid reason for
it. The comment in the file says
| For now, this API is only used from within a workqueue context;
| - * raw_spin_lock() is enough.
that is not it.
Understood. I will convert it in v2.
Thanks for the feedback!
Emil
