[PATCH net v2 2/2] strparser: don't serialize all parser work on one ordered workqueue

[Rishikesh Jethwani <rjethwani@purestorage.com>]

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 <rjethwani@purestorage.com>
---
 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