via-velocity skb_over_panic

Hi,

I recently saw via-velocity skb_over_panic() on one of my locations.
The panic happened with two separate hardware devices, so it appears to
be network related, not broken hardware.

I did not get the actual over_panic printk, as I got only screen shot
of them monitor. But the visible part of call trace says:
 <IRQ>
 skb_put
 velocity_poll
 net_rx_action
 __do_softirq
 irq_exit
 common_interrupt
 <EOI>

The was recurring every few hours, so I patched via-velocity with the
following after looking the code a bit:


This seems to have fixed the panics. And I do see one of the NIC's
ethtool report's in_range_length_errors increasing once in a while. For
some reason I don't see the above debug message though, so I'm not sure
on what pkt_len triggers it.

In any case, the cade a bit later on does unconditionally:
	skb_put(skb, pkt_len - 4);

So it's possible that some bad packets make the NIC return unexpected
packet sizes, and the current code can panic on it.

Any suggestions for better fix?

Thanks,
Timo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Timo Teras <timo.teras@iki.fi>
Date: Fri, 13 Nov 2015 18:49:47 +0200

> +	if (pkt_len < 4 || pkt_len > vptr->rx.buf_sz) {
> +		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame size %d is inconsistent.\n", vptr->netdev->name, pkt_len);
 ...
> This seems to have fixed the panics. And I do see one of the NIC's
> ethtool report's in_range_length_errors increasing once in a while. For
> some reason I don't see the above debug message though, so I'm not sure
> on what pkt_len triggers it.

You have to set the driver message level >= MSG_LEVEL_VERBOSE (3) to
see it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Timo Teras <timo.teras@iki.fi> :
[...]
> So it's possible that some bad packets make the NIC return unexpected
> packet sizes, and the current code can panic on it.
> 
> Any suggestions for better fix?

        if (vptr->flags & VELOCITY_FLAGS_VAL_PKT_LEN) {
                if (rd->rdesc0.RSR & RSR_RL) {

Huh ?

[...]
        velocity_set_bool_opt(&opts->flags, ValPktLen[index], VAL_PKT_LEN_DEF, VELOCITY_FLAGS_VAL_PKT_LEN, "ValPktLen", devname);
[...]
#define VAL_PKT_LEN_DEF     0
/* ValPktLen[] is used for setting the checksum offload ability of NIC.
   0: Receive frame with invalid layer 2 length (Default)
   1: Drop frame with invalid layer 2 length
*/
VELOCITY_PARAM(ValPktLen, "Receiving or Drop invalid 802.3 frame");

*spleen*

RSR_RL should be set on packet length error. You can imnsvho remove the
VELOCITY_FLAGS_VAL_PKT_LEN and VAL_PKT_LEN_DEF stuff altogether.
He who cares about this option should add NETIF_F_RXALL support to the
via-velocity driver.