On Wed, 2009-10-21 at 23:19 +0200, Jarek Poplawski wrote: > On Wed, Oct 21, 2009 at 08:46:40PM +0200, Tilman Schmidt wrote: > ... > > I have tested your patch and I can confirm that it fixes the messages. > > I have not noticed any ill effects. > > OK. So, in any case, here is this next variant/proposal. > > Thanks, > Jarek P. > ------------------------> > net: Adjust softirq raising in __napi_schedule > > This patch changes __raise_softirq_irqoff() to raise_softirq_irqoff() > in __napi_schedule() to enable proper softirq scheduling from process > context. The main intent is to let use netif_rx() universally, and > make netif_rx_ni() redundant. > > Currently using netif_rx() instead of netif_rx_ni() triggers: > "NOHZ: local_softirq_pending 08" warnings, but additional cost of one > "if" on the fast path doesn't seem to justify maintaining it > separately. > > This patch is based on the analysis, suggestions and the original > patch for mac80211 by: Michael Buesch <mb@xxxxxxxxx> > > Another patch calling netif_rx variants conditionally was done by: > Oliver Hartkopp <oliver@xxxxxxxxxxxx> > > Reported-by: Michael Buesch <mb@xxxxxxxxx> > Reported-by: Oliver Hartkopp <oliver@xxxxxxxxxxxx> > Reported-by: Tilman Schmidt <tilman@xxxxxxx> > Diagnosed-by: Michael Buesch <mb@xxxxxxxxx> > Tested-by: Tilman Schmidt <tilman@xxxxxxx> > Signed-off-by: Jarek Poplawski <jarkao2@xxxxxxxxx> > --- > > net/core/dev.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 28b0b9e..7fc4009 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2728,7 +2728,7 @@ void __napi_schedule(struct napi_struct *n) > > local_irq_save(flags); > list_add_tail(&n->poll_list, &__get_cpu_var(softnet_data).poll_list); > - __raise_softirq_irqoff(NET_RX_SOFTIRQ); > + raise_softirq_irqoff(NET_RX_SOFTIRQ); This still doesn't make any sense. There may or may not be a lot of code that assumes that everything else is run with other tasklets disabled, and that it cannot be interrupted by a tasklet and thus create a race. Can you prove that is not the case, across the entire networking layer? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
