On Tue, 2009-10-27 at 01:52 +0100, Tilman Schmidt wrote: > > Any code (say ISDN code) that calls netif_rx() is clearly assuming to > > always be running in (soft)irq context, otherwise it couldn't call > > netif_rx() unconditionally. Agree so far? > > Well, in fact I'm not sure. :-) All I know is that in the ISDN case, no > such assumption is explicitly stated anywhere. (The code in question is > called from the rcvcallb_skb() callback method which the hardware driver > calls when data has been received, and the description of that method in > Documentation/isdn/INTERFACE does not say anything about the context in > which it may be called.) The relevant code in drivers/isdn/i4l/isdn_ppp.c > is rather old, perhaps even older than softirqs and the netif_rx() / > netif_rx_ni() split. (Bear in mind that we are talking about the old > ISDN4Linux subsystem which initially didn't even make it into the 2.6 > series because it was considered obsolete.) It seems quite possible to me > that just no one ever thought about that question. Heh :) > > So now if you change the ISDN code to call netif_rx_ni(), you've changed > > the assumption that the ISDN code makes -- that it is running in > > (soft)irq context. Therefore, you need to verify that this is actually a > > correct change, which is what I tried to say. > > Understood. However, the fact that the local_softirq_pending message is > appearing would seem to indicate that this assumption was wrong to > begin with, wouldn't it? I thought it only recently started appearing with a new driver or something, but I may have misunderstood you. Anyway, I think that sums up the issue from my POV. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
