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. > Thanks, > Emil Sebastian
