Am 26.10.2009 09:56 schrieb Johannes Berg: > On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote: > >>> Basically it boils down to using netif_rx() when in (soft)irq, and >>> netif_rx_ni() when in process context. That could just be an >>> optimisation, but it's a very valid one. >> Hmmm. That seems to contradict your earlier statement to me that >> simply replacing a call to netif_rx() by one to netif_rx_ni() >> when not in interrupt context isn't a valid solution either. >> What am I missing? > > Well, I think you misunderstood me. It would be correct to do this, if > and only if the code that calls it doesn't need the extra guarantee. I see. Thanks for the clarification. > 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. > 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? Thanks, Tilman -- Tilman Schmidt E-Mail: tilman@xxxxxxx Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Attachment:
signature.asc
Description: OpenPGP digital signature
