Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
On Sun, Nov 08, 2009 at 01:05:33AM -0800, David Miller wrote: ... When using KGDBoE, gianfar driver spits 'Interrupt problem' messages, which appears to be a legitimate warning, i.e. we may end up calling netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled. This patch reworks the RX path so that if netpoll is enabled (the only case when the driver don't know from what context the polling may be called), we check whether IRQs are disabled, and if so we fall back to safe variants of skb receiving functions. This is bogus, I'll tell you why. When you go into netif_receive_skb() we have a special check, if (netpoll_receive_skb(... that takes care of all of the details concerning doing a -poll() from IRQ disabled context via netpoll. So this code you're adding should not be necessary. Or, explain to me why no other driver needs special logic in their -poll() handler like this and does not run into any kinds of netpoll problems :-) Hm, I was confused by the following note: /** * netif_receive_skb - process receive buffer from network * @skb: buffer to process ... * This function may only be called from softirq context and interrupts * should be enabled. Looking into the code though, I can indeed see that there are netpoll checks, and __netpoll_rx() is actually called with irqs disabled. So, in the end it appears that we should just remove the 'Interrupt problem' message. Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
From: Anton Vorontsov avoront...@ru.mvista.com Date: Thu, 5 Nov 2009 01:57:11 +0300 When using KGDBoE, gianfar driver spits 'Interrupt problem' messages, which appears to be a legitimate warning, i.e. we may end up calling netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled. This patch reworks the RX path so that if netpoll is enabled (the only case when the driver don't know from what context the polling may be called), we check whether IRQs are disabled, and if so we fall back to safe variants of skb receiving functions. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com This is bogus, I'll tell you why. When you go into netif_receive_skb() we have a special check, if (netpoll_receive_skb(... that takes care of all of the details concerning doing a -poll() from IRQ disabled context via netpoll. So this code you're adding should not be necessary. Or, explain to me why no other driver needs special logic in their -poll() handler like this and does not run into any kinds of netpoll problems :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC] gianfar: Make polling safe with IRQs disabled
When using KGDBoE, gianfar driver spits 'Interrupt problem' messages,
which appears to be a legitimate warning, i.e. we may end up calling
netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled.
This patch reworks the RX path so that if netpoll is enabled (the
only case when the driver don't know from what context the polling
may be called), we check whether IRQs are disabled, and if so we
fall back to safe variants of skb receiving functions.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
I'm not sure if this is suitable for mainline since it doesn't
have KGDBoE support. Jason, if the patch is OK, would you like
to merge it into KGDB tree?
drivers/net/gianfar.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 197b358..024ca4a 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2412,9 +2412,17 @@ static int gfar_process_frame(struct net_device *dev,
struct sk_buff *skb,
{
struct gfar_private *priv = netdev_priv(dev);
struct rxfcb *fcb = NULL;
-
+ int irqs_dis = 0;
int ret;
+ /*
+* With netpoll we don't know from what context we're called (e.g
+* KGDBoE may call us from an exception handler), otherwise we're
+* pretty sure that IRQs are enabled.
+*/
+#ifdef CONFIG_NETPOLL
+ irqs_dis = irqs_disabled();
+#endif
/* fcb is at the beginning if exists */
fcb = (struct rxfcb *)skb-data;
@@ -2432,7 +2440,10 @@ static int gfar_process_frame(struct net_device *dev,
struct sk_buff *skb,
/* Send the packet up the stack */
if (unlikely(priv-vlgrp (fcb-flags RXFCB_VLN)))
- ret = vlan_hwaccel_receive_skb(skb, priv-vlgrp, fcb-vlctl);
+ ret = __vlan_hwaccel_rx(skb, priv-vlgrp, fcb-vlctl,
+ !irqs_dis);
+ else if (irqs_dis)
+ ret = netif_rx(skb);
else
ret = netif_receive_skb(skb);
@@ -2504,8 +2515,6 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue,
int rx_work_limit)
skb_put(skb, pkt_len);
dev-stats.rx_bytes += pkt_len;
- if (in_irq() || irqs_disabled())
- printk(Interrupt problem!\n);
gfar_process_frame(dev, skb, amount_pull);
} else {
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
