Re: tun.c patch to fix "smp_processor_id() in preemptible code"

[Lee Revell]

On Sun, 2004-10-17 at 16:14, Denis Vlasenko wrote:
> > Your patch:
> > 
> > +       preempt_disable();
> >         netif_rx_ni(skb);
> > +       preempt_enable();
> > 
> > just wraps this code in preempt_disable/enable:
> > 
> > static inline int netif_rx_ni(struct sk_buff *skb)
> > {
> >        int err = netif_rx(skb);
> >        if (softirq_pending(smp_processor_id()))
> >                do_softirq();
> >        return err;
> > }
> > 
> > Isn't this considered an incorrect use of preempt_disable/enable?  My
> > reasoning is that if this was correct we would see preempt_dis/enable
> > sprinkled all over the code which it isn't.
> > 
> > Why do you have to call do_softirq like that?  I was under the
> > impression that you raise a softirq and it gets run later.
> 
> There is a possibility that this guy just wanted to fix his
> small problem.
> 

Yes, that is what I thought.  The question was more directed at the
list.  I added netdev to the cc:.  

I looked at Robert Love's book and I am still unclear on the use of
do_softirq above.  To reiterate the question:  why does netif_rx_ni have
to manually flush any pending softirqs on the current proccessor after
doing the rx?  Is this just a performance hack?

Lee


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/