gainfar.c : skb_over_panic (kernel-2.6.32.15)
in [Kernel]
|
Prev: [PATCH 2/7] perf: Fix argument of perf_arch_fetch_caller_regs
Next: 2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)
From: David Miller on 24 Jun 2010 18:00 From: Eran Liberty <liberty(a)extricom.com> Date: Thu, 24 Jun 2010 12:53:23 +0300 > Fix possible skb_over_panic event in Freescale's "gianfar" driver. > > The skb_over_panic occurs due to calling skb_put() within > gfar_clean_rx_ring(). This happens if (and only if) shortly prior to > the event and a few lined above the skb_put(), an skb was queued back > to the priv->rx_recycle queue due to RXBD_LAST or RXBD_ERR status. > The skb is queued without properly re-setting its state. > > The patch properly reset the skb state. > > I have tested this patch on MPC8548 based product and asserted it > avoided the skb_over_panic event. > > Signed-off-by: Eran Liberty <liberty(a)extricom.com> Eran, this seems to be fixed already. The code in the current tree now reads: /* * We need to un-reserve() the skb to what it * was before gfar_new_skb() re-aligned * it to an RXBUF_ALIGNMENT boundary * before we put the skb back on the * recycle list. */ skb_reserve(skb, -GFAR_CB(skb)->alignamount); __skb_queue_head(&priv->rx_recycle, skb); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eran Liberty on 28 Jun 2010 04:10 David Miller wrote: > From: Eran Liberty <liberty(a)extricom.com> > Date: Thu, 24 Jun 2010 12:53:23 +0300 > > >> Fix possible skb_over_panic event in Freescale's "gianfar" driver. >> >> The skb_over_panic occurs due to calling skb_put() within >> gfar_clean_rx_ring(). This happens if (and only if) shortly prior to >> the event and a few lined above the skb_put(), an skb was queued back >> to the priv->rx_recycle queue due to RXBD_LAST or RXBD_ERR status. >> The skb is queued without properly re-setting its state. >> >> The patch properly reset the skb state. >> >> I have tested this patch on MPC8548 based product and asserted it >> avoided the skb_over_panic event. >> >> Signed-off-by: Eran Liberty <liberty(a)extricom.com> >> > > Eran, this seems to be fixed already. The code in the current > tree now reads: > > /* > * We need to un-reserve() the skb to what it > * was before gfar_new_skb() re-aligned > * it to an RXBUF_ALIGNMENT boundary > * before we put the skb back on the > * recycle list. > */ > skb_reserve(skb, -GFAR_CB(skb)->alignamount); > __skb_queue_head(&priv->rx_recycle, skb); > > > This code has proved to be insufficient and produce skb_over_panic. The proposed patch fix this. -- Liberty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 28 Jun 2010 14:40
From: Eran Liberty <liberty(a)extricom.com> Date: Mon, 28 Jun 2010 10:57:08 +0300 > This code has proved to be insufficient and produce > skb_over_panic. The proposed patch fix this. Then you have to post a patch relative to the current code, rather than against the code as it was several releases ago. Your patch didn't apply, so I can't use it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |