Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200723091715.GL19262@shao2-debian> <87v9iexztl.fsf@nanos.tec.linutronix.de>
 <CAKc596KA2moT7fgO+Ount5trEbtrYsuLbde5S5Ou-c4EQbHb3g@mail.gmail.com> <874kpyxpro.fsf@nanos.tec.linutronix.de>
In-Reply-To: <874kpyxpro.fsf@nanos.tec.linutronix.de>
From:   jun qian <qianjun.kernel@gmail.com>
Date:   Fri, 24 Jul 2020 13:35:17 +0800
Message-ID: <CAKc596Lp3m3Ny9joOckYPsR5Lmok978bceMYNBrzsk6ozFjqhw@mail.gmail.com>
Subject: Re: [Softirq] a76eadba0d: WARNING:at_net/mac80211/rx.c:#ieee80211_rx_napi[mac80211]
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     kernel test robot <lkp@intel.com>, peterz@infradead.org,
        will@kernel.org, luto@kernel.org, linux-kernel@vger.kernel.org,
        Uladzislau Rezki <urezki@gmail.com>,
        Yafang Shao <laoar.shao@gmail.com>, lkp@lists.01.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 23, 2020 at 10:35 PM Thomas Gleixner <tglx@linutronix.de> wrote=
:
>
> jun qian <qianjun.kernel@gmail.com> writes:
> > On Thu, Jul 23, 2020 at 6:58 PM Thomas Gleixner <tglx@linutronix.de> wr=
ote:
> >> That drops everything which has not yet been processed and the above
> >> warning is due to this.
> >>
> > wow, I made a mistake, thank you for finding the cause of the problem
> > so quickly.
> >
> > How about the following code.   we need to clear the corresponding
> > pending bit at the
> > right time Instead of all the pending bits cleared in the start.
> >
> > pending =3D softirq_pending();
> >
> > while ((softirq_bit =3D ffs(pending))) {
> >
> >         pending >>=3D softirq_bit;
> >
> >         set_softirq_pending(pending);  //Only clear the corresponding
> > bit which will be processed.
>
> How is that supposed to be correct. pending has been shifted
> right. Something like this should work:
>
>                 h++;
>                 pending >>=3D softirq_bit;
>
>                 if (timeout()) {
>                         /*
>                          * Ensure that the remaining pending bits
>                          * are handled.
>                          */
>                         or_softirq_pending(pending << (vec_nr + 1));
>                         break;
>                 }
>         }
>
> Thanks,
>
>         tglx
>

I have two questions that need to be discussed.

1. If the __do_sofrirq() is executed in the ksoftirqd, we may not need
to check the timeout in the loop.
2. Both the invoke_softirq() and run_ksoftirqd()  will execute
__do_sofirq, they all execute the same code=EF=BC=8C
    when it is in the ksoftirqd, Do we need to wake up ksoftirqd in
the process context according to
    max_restart and MAX_SOFTIRQ_TIME. In my opinion, If we  use a flag
to distinguish where
    __do_softirq() is called from,  we can do what is most suitable
for __do_softirq based on this flag.