On Tue, Mar 2, 2021 at 3:18 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, 2021-02-24 at 10:30 +0800, Hillf Danton wrote:
> >
> > 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)
