strp_wq has been created with create_singlethread_workqueue() since strparser was introduced, which makes it an ordered workqueue: at most one strparser work item runs at a time, system-wide. Every strparser user shares it: KCM, sockmap, espintcp and ovpn's TCP transport, and every instance's msg_timer_work. strp_work() takes cb.lock before reading, and every in-tree user leaves cb.lock at its default, lock_sock(). The single kstrp worker therefore already stalls for as long as any process holds the socket lock of any strparser-attached socket, delaying parsing and message timeouts for every other socket using strparser. The same applies to work that is slow for other reasons, such as a lower socket's read_sock() doing software decryption, which is what KCM over kTLS does now that the previous patch moves its parsing to kstrp. Nothing relies on the ordering: - The workqueue core never runs one work item on two workers at once, so a given strparser's work stays serialized with itself. - strp_work() and strp_msg_timeout() both run under cb.lock, so they are serialized against each other per socket by the socket lock, and strp_abort_strp() is idempotent through strp->stopped. - strp_done() cancels both with the _sync variants, which work on any workqueue. - Different strparsers were never ordered against each other: the common strp_data_ready() path runs inline in softirq on whichever CPU received the data, bypassing the workqueue entirely. Allocate kstrp as a per-CPU, WQ_MEM_RECLAIM workqueue instead. kTLS's tls-strp workqueue has the same flags, via create_workqueue(), but caps max_active at 1 per CPU; kstrp uses the default limit (1024 per CPU), so a work item blocked on a socket lock does not hold up others queued on the same CPU. A per-CPU workqueue keeps the work local to the CPU that received the data, like tls-strp; work that stays CPU-bound for long is excluded from concurrency management by the workqueue core's CPU-intensive detection. This lets strparser work for different sockets run concurrently for every user of strparser, not only KCM. Without it, the previous patch would let one KCM psock doing software kTLS decryption on kstrp delay parsing and message timeouts for every other strparser socket. Tested with test_sockmap and the ovpn TCP selftests; strparser work now runs concurrently across sockets with no dmesg warnings. Signed-off-by: Rishikesh Jethwani --- net/strparser/strparser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c index d5b17d099a0e..32fe96ba10d6 100644 --- a/net/strparser/strparser.c +++ b/net/strparser/strparser.c @@ -542,7 +542,7 @@ static int __init strp_dev_init(void) BUILD_BUG_ON(sizeof(struct sk_skb_cb) > sizeof_field(struct sk_buff, cb)); - strp_wq = create_singlethread_workqueue("kstrp"); + strp_wq = alloc_workqueue("kstrp", WQ_PERCPU | WQ_MEM_RECLAIM, 0); if (unlikely(!strp_wq)) return -ENOMEM; -- 2.50.1