Re: BUG: soft lockup in ieee80211_tasklet_handler

On Tue, Mar 2, 2021 at 3:18 PM Johannes Berg [off-list ref] wrote:

On Wed, 2021-02-24 at 10:30 +0800, Hillf Danton wrote:

quoted

Add budget for the 80211 softint handler - it's feasible not to try to
build the giant pyramid in a week.

--- x/net/mac80211/main.c
+++ y/net/mac80211/main.c

@@ -224,9 +224,15 @@ static void ieee80211_tasklet_handler(un
 {
      struct ieee80211_local *local = (struct ieee80211_local *) data;
      struct sk_buff *skb;
+     int i = 0;
+
+     while (i++ < 64) {
+             skb = skb_dequeue(&local->skb_queue);
+             if (!skb)
+                     skb = skb_dequeue(&local->skb_queue_unreliable);
+             if (!skb)
+                     return;

I guess that's not such a bad idea, but I do wonder how we get here,
userspace can submit packets faster than we can process?

It feels like a simulation-only case, tbh, since over the air you have
limits how much bandwidth you can get ... unless you have a very slow
CPU?

In any case, if you want anything merged you're going to have to submit
a proper patch with a real commit message and Signed-off-by, etc.

Looking at the reproducer that mostly contains just perf_event_open,
It may be the old known issue of perf_event_open with some extreme
parameters bringing down kernel.
+perf maintainers
And as far as I remember +Peter had some patch to restrict
perf_event_open parameters.

r0 = perf_event_open(&(0x7f000001d000)={0x1, 0x70, 0x0, 0x0, 0x0, 0x0,
0x0, 0x3ff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xfffffffe, 0x0, @perf_config_ext}, 0x0,
0x0, 0xffffffffffffffff, 0x0)