* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 14:44 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AD7B82@IRSMSX108.ger.corp.intel.com>
On 12/18/14, 3:29 AM, Varlese, Marco wrote:
> From: Marco Varlese <marco.varlese@intel.com>
>
> Switch hardware offers a list of attributes that are configurable
> on a per port basis.
> This patch provides a mechanism to configure switch ports by adding
> an NDO for setting specific values to specific attributes.
> There will be a separate patch that adds the "get" functionality via
> another NDO and another patch that extends iproute2 to call the two
> new NDOs.
>
> Signed-off-by: Marco Varlese <marco.varlese@intel.com>
> ---
> include/linux/netdevice.h | 5 ++++
> include/uapi/linux/if_link.h | 15 ++++++++++++
> net/core/rtnetlink.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 74 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index c31f74d..4881c7b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
> * Called to notify switch device port of bridge port STP
> * state change.
> + * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
> + * u32 attr, u64 value);
> + * Called to set specific switch ports attributes.
> */
> struct net_device_ops {
> int (*ndo_init)(struct net_device *dev);
> @@ -1185,6 +1188,8 @@ struct net_device_ops {
> struct netdev_phys_item_id *psid);
> int (*ndo_switch_port_stp_update)(struct net_device *dev,
> u8 state);
> + int (*ndo_switch_port_set_cfg)(struct net_device *dev,
> + u32 attr, u64 value);
> #endif
> };
>
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index f7d0d2d..19cb51a 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -146,6 +146,7 @@ enum {
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> IFLA_PHYS_SWITCH_ID,
> + IFLA_SWITCH_PORT_CFG,
> __IFLA_MAX
> };
>
> @@ -603,4 +604,18 @@ enum {
>
> #define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
>
> +/* Switch Port Attributes section */
> +
> +enum {
> + IFLA_ATTR_UNSPEC,
> + IFLA_ATTR_LEARNING,
Any reason you want learning here ?. This is covered as part of the
bridge setlink attributes.
> + IFLA_ATTR_LOOPBACK,
> + IFLA_ATTR_BCAST_FLOODING,
> + IFLA_ATTR_UCAST_FLOODING,
> + IFLA_ATTR_MCAST_FLOODING,
> + __IFLA_ATTR_MAX
> +};
> +
> +#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
> +
> #endif /* _UAPI_LINUX_IF_LINK_H */
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index eaa057f..c0d1c45 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1389,6 +1389,46 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
> return 0;
> }
>
> +#ifdef CONFIG_NET_SWITCHDEV
> +static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
> +{
> + int rem, err = -EINVAL;
> + struct nlattr *v;
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + nla_for_each_nested(v, attr, rem) {
> + u32 op = nla_type(v);
> + u64 value = 0;
> +
> + switch (op) {
> + case IFLA_ATTR_LEARNING:
> + case IFLA_ATTR_LOOPBACK:
> + case IFLA_ATTR_BCAST_FLOODING:
> + case IFLA_ATTR_UCAST_FLOODING:
> + case IFLA_ATTR_MCAST_FLOODING: {
> + if (nla_len(v) < sizeof(value)) {
> + err = -EINVAL;
> + break;
> + }
> +
> + value = nla_get_u64(v);
> + err = ops->ndo_switch_port_set_cfg(dev,
> + op,
> + value);
> + break;
> + }
> + default:
> + err = -EINVAL;
> + break;
> + }
> + if (err)
> + break;
> + }
> + return err;
> +}
> +
> +#endif
> +
> static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
> {
> int rem, err = -EINVAL;
> @@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
> status |= DO_SETLINK_NOTIFY;
> }
> }
> +#ifdef CONFIG_NET_SWITCHDEV
> + if (tb[IFLA_SWITCH_PORT_CFG]) {
> + err = -EOPNOTSUPP;
> + if (!ops->ndo_switch_port_set_cfg)
> + goto errout;
> + if (!ops->ndo_switch_parent_id_get)
> + goto errout;
> + err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
> + if (err < 0)
> + goto errout;
> +
> + status |= DO_SETLINK_NOTIFY;
> + }
> +#endif
> err = 0;
>
> errout:
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Thomas Graf @ 2014-12-18 13:58 UTC (permalink / raw)
To: Vadim Kochan
Cc: Daniel Borkmann, Marcelo Ricardo Leitner, Stephen Hemminger,
netdev, jhs
In-Reply-To: <20141218134621.GA9985@angus-think.lan>
On 12/18/14 at 03:46pm, Vadim Kochan wrote:
> On Thu, Dec 18, 2014 at 02:47:38PM +0100, Daniel Borkmann wrote:
> > On 12/18/2014 02:16 PM, Vadim Kochan wrote:
> > ...
> > >The problem that this is huge now but looks better visually, I am
> > >thinking also about to possibiliy to show only some part of tree by specified parent id ...
> >
> > I definitely like this work!
> >
> > Just thinking out loud, what about an output option for tc which is plain
> > DOT [1], thus it can be handed over for rendering in tools like graphviz?
> >
> > It won't require any dependencies either as it's just plaintext.
> >
> > [1] https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29
>
> Yeah, good idea :-)
tcng had something like that ;-)
^ permalink raw reply
* Re: [PATCH net] enic: fix rx skb checksum
From: Sergei Shtylyov @ 2014-12-18 13:58 UTC (permalink / raw)
To: Govindarajulu Varadarajan, davem, netdev, ssujith, benve
Cc: Jiri Benc, Stefan Assmann
In-Reply-To: <1418898522-13588-1-git-send-email-_govind@gmx.com>
Hello.
On 12/18/2014 1:28 PM, Govindarajulu Varadarajan wrote:
> Hardware always provides compliment of IP pseudo checksum. Stack expects
> whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.
> This causes checksum error in nf & ovs.
> kernel: qg-19546f09-f2: hw csum failure
> kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1
> kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
> kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
> kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
> kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
> kernel: Call Trace:
> kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b
> kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
> kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
> kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
> kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
> kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
> kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
> kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
> kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
> kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
> kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
> kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
> kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380
> Hardware verifies IP & tcp/udp header checksum but does not provide payload
> checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.
> Cc: Jiri Benc <jbenc@redhat.com>
> Cc: Stefan Assmann <sassmann@redhat.com>
> Reported-by: Sunil Choudhary <schoudha@redhat.com>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
> ---
> drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
> diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
> index 868d0f6..705f334 100644
> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
> @@ -1060,10 +1060,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
> PKT_HASH_TYPE_L4 : PKT_HASH_TYPE_L3);
> }
>
> - if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
> - skb->csum = htons(checksum);
> - skb->ip_summed = CHECKSUM_COMPLETE;
> - }
> + /* Hardware does not provide whole packet checksum. It only
> + * provides pseudo checksum. Since hw validates the packet
> + * checksum but not provide us the checksum value. use
s/not/doesn't/, s/value./value,/.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Vadim Kochan @ 2014-12-18 13:46 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Vadim Kochan, Marcelo Ricardo Leitner, Stephen Hemminger, netdev,
jhs
In-Reply-To: <5492DAFA.5070001@redhat.com>
On Thu, Dec 18, 2014 at 02:47:38PM +0100, Daniel Borkmann wrote:
> On 12/18/2014 02:16 PM, Vadim Kochan wrote:
> ...
> >The problem that this is huge now but looks better visually, I am
> >thinking also about to possibiliy to show only some part of tree by specified parent id ...
>
> I definitely like this work!
>
> Just thinking out loud, what about an output option for tc which is plain
> DOT [1], thus it can be handed over for rendering in tools like graphviz?
>
> It won't require any dependencies either as it's just plaintext.
>
> [1] https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29
Yeah, good idea :-)
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Daniel Borkmann @ 2014-12-18 13:47 UTC (permalink / raw)
To: Vadim Kochan; +Cc: Marcelo Ricardo Leitner, Stephen Hemminger, netdev, jhs
In-Reply-To: <20141218131653.GA5980@angus-think.lan>
On 12/18/2014 02:16 PM, Vadim Kochan wrote:
...
> The problem that this is huge now but looks better visually, I am
> thinking also about to possibiliy to show only some part of tree by specified parent id ...
I definitely like this work!
Just thinking out loud, what about an output option for tc which is plain
DOT [1], thus it can be handed over for rendering in tools like graphviz?
It won't require any dependencies either as it's just plaintext.
[1] https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Vadim Kochan @ 2014-12-18 13:16 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Vadim Kochan, Stephen Hemminger, netdev
In-Reply-To: <5492CC8E.6050108@gmail.com>
On Thu, Dec 18, 2014 at 10:46:06AM -0200, Marcelo Ricardo Leitner wrote:
> On 18-12-2014 10:23, Vadim Kochan wrote:
> >On Thu, Dec 18, 2014 at 10:26:37AM -0200, Marcelo Ricardo Leitner wrote:
> >>>+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | * Send 100 pkts ...
> >>> | * Rate 10mbit ...
> >>> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> >>> | | * Send 100 pkts ...
> >>> | | * Rate 10mbit ...
> >>> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | | | * Send 100 pkts ...
> >>> | | | * Rate 10mbit ...
> >>> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | | | | * Send 100 pkts ...
> >>> | | | | * Rate 10mbit ...
> >> ^ these are confusing IMHO, rest looks good to me
> >>
> >> Marcelo
> >>
> >
> >
> >Yes, just fixed it to :
>
> Cool
>
> >+---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >| | * Send 100 pkts ...
> >| | * Rate 10mbit ...
> >| +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> >| | * Send 100 pkts ...
> >| | * Rate 10mbit ...
> >| +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >| | * Send 100 pkts ...
> >| | * Rate 10mbit ...
> >| +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >| * Send 100 pkts ...
> >| * Rate 10mbit ...
> >|
> >+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | * Send 100 pkts ...
> > | * Rate 10mbit ...
> > +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> > | | * Send 100 pkts ...
> > | | * Rate 10mbit ...
> > | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | | * Send 100 pkts ...
> > | | | * Rate 10mbit ...
> > | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | | * Send 100 pkts ...
> > | | | * Rate 10mbit ...
> > | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | * Send 100 pkts ...
> > | | * Rate 10mbit ...
> > | |
> > | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | * Send 100 pkts ...
> > | * Rate 10mbit ...
> > |
> > +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | * Send 100 pkts ...
> > | * Rate 10mbit ...
> > +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > * Send 100 pkts ...
> > * Rate 10mbit ...
> >
> >I am not sure about the better format to print stats - use '*' or '>' as
> >prefix, '*' - seems better ?
>
> TBH I don't think we need one in there. It's already linked to the items due
> to the tree on them. If you just align them to start right where the the
> first word after the ')' begins, it would be good. Like:
>
> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | Send 100 pkts ...
> | | | Rate 10mbit ...
> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst
> 1599b
> | | | Send 100 pkts ...
> | | | Rate 10mbit ...
> | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst
> 1599b
>
> But I don't know how large this will get..
>
> Yet I don't mind having one marker in there. Let's see what others think
> about it.
>
> Regards,
> Marcelo
>
I corrected regarding to your comments:
+---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | Send 100 pkts ...
| | Rate 10mbit ...
| |
| +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | Send 100 pkts ...
| | Rate 10mbit ...
| |
| +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | Send 100 pkts ...
| | Rate 10mbit ...
| |
| +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| Send 100 pkts ...
| Rate 10mbit ...
|
+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| Send 100 pkts ...
| Rate 10mbit ...
|
+---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | Send 100 pkts ...
| | Rate 10mbit ...
| |
| +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | Send 100 pkts ...
| | | Rate 10mbit ...
| | |
| | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | | Send 100 pkts ...
| | | Rate 10mbit ...
| | |
| | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | Send 100 pkts ...
| | Rate 10mbit ...
| |
| +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| Send 100 pkts ...
| Rate 10mbit ...
|
+---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| Send 100 pkts ...
| Rate 10mbit ...
|
+---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
Send 100 pkts ...
Rate 10mbit ...
The problem that this is huge now but looks better visually, I am
thinking also about to possibiliy to show only some part of tree by specified parent id ...
But how much classes can be used usually for traffic control per device ?
Regards,
Vadim Kochan
^ permalink raw reply
* Re: Bug: mv643xxx fails with highmem
From: Ezequiel Garcia @ 2014-12-18 13:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: David Miller, Nimrod Andy, Fabio Estevam, netdev, fugang.duan
In-Reply-To: <20141218000357.GX11285@n2100.arm.linux.org.uk>
On 12/17/2014 09:03 PM, Russell King - ARM Linux wrote:
> On Wed, Dec 17, 2014 at 06:18:58PM -0300, Ezequiel Garcia wrote:
>> On the other side, I haven't been able to reproduce this on my boards. I
>> did try to put a hack to hold most lowmem pages, but it didn't make a
>> difference. (In fact, I haven't been able to clearly see how the pages
>> for the skbuff are allocated from high memory.)
>
> To be honest, I don't know either. All that I can do is describe what
> happened...
>
> I've been running 3.17 since a week after it came out, and never saw a
> problem there.
>
> Then I moved forward to 3.18, and ended up with memory corruption, which
> seemed to be the GPU scribbling over kernel text (since the oops revealed
> pixel values in the Code: line.)
>
> I thought it was a GPU problem - which seemed a reasonable assumption as
> I know that the runtime PM I implemented for the GPU doesn't properly
> restore the hardware state yet. So, I rebooted back into 3.18, this
> time with all GPU users disabled, intending to download a kernel with
> GPU runtime PM disabled. I'd also added additional debug to my X DDX
> driver which logged the GPU command stream to a file on a NFS mount -
> this does open(, O_CREAT|O_WRONLY|O_APPEND), write(), close() each
> time it submits a block of commands.
>
> However, while my scripts to download the built kernel to the Cubox
> were running, the kernel oopsed in the depths of dma_map_single() - the
> kernel was trying to access a struct page for phys address 0x40000000,
> which didn't exist. I decided to go back to 3.17 to get the updated
> kernel on it, hoping that would sort it out.
>
> With the updated 3.18 kernel (with GPU runtime PM disabled), I found
> that I'd still get oopses in from the network driver while X was starting
> up, again from dma_map_single(). So, with all GPU users again disabled,
> I set about debugging the this issue.
>
> I added a BUG_ON(!addr) after the page_address(), and that fired. I
> added a BUG_ON(PageHighMem(this_frag->page.p)) and that fired too.
> (Each time, I had to boot back to 3.17 in order to download the new
> kernel, because very time I tried with 3.18, I'd hit this bug.)
>
> It's then when I reported the issue and asked the questions...
>
> I've since done a simple change, taking advantage that on ARM (or any
> asm-generic/dma-mapping-common.h user), dma_unmap_single() and
> dma_unmap_page() are the same function:
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index d44560d1d268..c343ab03ab8b 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -879,10 +879,8 @@ static void txq_submit_frag_skb(struct tx_queue *txq, struct sk_buff *skb)
> skb_frag_t *this_frag;
> int tx_index;
> struct tx_desc *desc;
> - void *addr;
>
> this_frag = &skb_shinfo(skb)->frags[frag];
> - addr = page_address(this_frag->page.p) + this_frag->page_offset; tx_index = txq->tx_curr_desc++;
> if (txq->tx_curr_desc == txq->tx_ring_size)
> txq->tx_curr_desc = 0;
> @@ -902,8 +900,9 @@ static void txq_submit_frag_skb(struct tx_queue *txq, struct sk_buff *skb)
>
> desc->l4i_chk = 0;
> desc->byte_cnt = skb_frag_size(this_frag);
> - desc->buf_ptr = dma_map_single(mp->dev->dev.parent, addr,
> - desc->byte_cnt, DMA_TO_DEVICE);
> + desc->buf_ptr = skb_frag_dma_map(mp->dev->dev.parent,
> + this_frag, 0,
> + desc->byte_cnt, DMA_TO_DEVICE); }
> }
>
>
> I've been running that for the last five days, and I've yet to see
> /any/ issues what so ever, and that includes running with the GPU
> logging all that time:
>
> -rw-r--r-- 1 root root 17113616 Dec 17 23:52 /shared/etnaviv.bin
>
> During that time, I've been using the device over the network, running
> various git commands, running builds, running the occasional build
> via NFS, etc.
>
> So, for me it was trivially easy to reproduce (without my fix in place)
> and all problems have gone away when I've fixed the apparent problem.
>
Well that's interesting. You've fixed only the non-TSO egress path,
yet your original ethtool output showed tcp-segmentation-offload enabled.
This seems to imply the highmem pages are found only for the non-TSO path.
> However, exactly how it occurs, I don't know. My understanding from
> reading the various feature flags was that NETIF_F_HIGHDMA was required
> for highmem (see illegal_highdma()) so as this isn't set, we shouldn't
> be seeing highmem fragments - which is why I asked the question in my
> original email.
>
> If you want me to revert my fix above, and reproduce again, I can
> certainly try that - or put a WARN_ON_ONCE(PageHighMem(this_frag->page.p))
> in there, but I seem to remember that it wasn't particularly useful as
> the backtrace didn't show where the memory actually came from.
>
No, that's OK. Thanks a lot for all the details. I'll try to come up with a
fix soon.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] brcmsmac: don't leak kernel memory via printk()
From: Arend van Spriel @ 2014-12-18 13:01 UTC (permalink / raw)
To: Brian Norris
Cc: John W. Linville, Kalle Valo, David S. Miller, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list, netdev
In-Reply-To: <CAN8TOE--Vfa1L8dcoV=up1bA+QX0_=+DkdDa7fAv6DJBF8PHow@mail.gmail.com>
On 12/18/14 07:32, Brian Norris wrote:
> + others [1]
>
> On Wed, Dec 10, 2014 at 1:39 AM, Brian Norris
> <computersforpeace@gmail.com> wrote:
>> Debug code prints the fifo name via custom dev_warn() wrappers. The
>> fifo_names array is only non-zero when debugging is manually enabled,
>> which is all well and good. However, it's *not* good that this array
>> uses zero-length arrays in the non-debug case, and so it doesn't
>> actually have any memory allocated to it. This means that as far as we
>> know, fifo_names[i] actually points to garbage memory.
>>
>> I've seen this in my log:
>>
>> [ 4601.205511] brcmsmac bcma0:1: wl0: brcms_c_d11hdrs_mac80211: �GeL txop exceeded phylen 137/256 dur 1602/1504
>>
>> So let's give this array space enough to fill it with a NULL byte.
>>
>> Signed-off-by: Brian Norris<computersforpeace@gmail.com>
>> Cc: Brett Rudley<brudley@broadcom.com>
>> Cc: Arend van Spriel<arend@broadcom.com>
>> Cc: "Franky (Zhenhui) Lin"<frankyl@broadcom.com>
>> Cc: Hante Meuleman<meuleman@broadcom.com>
>> Cc: "John W. Linville"<linville@tuxdriver.com>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: brcm80211-dev-list@broadcom.com
>> Cc: netdev@vger.kernel.org
>
> BTW, I guess this qualifies as a security hole, albeit a small one.
> Should this be CC: stable@vger.kernel.org?
I have no strong opinion on this, but I guess. Feel free to do so.
Regards,
Arend
>> ---
>> drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
>> index 1b474828d5b8..aed0c948dce8 100644
>> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
>> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
>> @@ -316,7 +316,7 @@ static const u16 xmtfifo_sz[][NFIFO] = {
>> static const char * const fifo_names[] = {
>> "AC_BK", "AC_BE", "AC_VI", "AC_VO", "BCMC", "ATIM" };
>> #else
>> -static const char fifo_names[6][0];
>> +static const char fifo_names[6][1];
>> #endif
>>
>> #ifdef DEBUG
>
> Brian
>
> [1] http://lwn.net/Articles/626689/
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Marcelo Ricardo Leitner @ 2014-12-18 12:46 UTC (permalink / raw)
To: Vadim Kochan; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20141218122329.GA31878@angus-think.lan>
On 18-12-2014 10:23, Vadim Kochan wrote:
> On Thu, Dec 18, 2014 at 10:26:37AM -0200, Marcelo Ricardo Leitner wrote:
>>> +---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | * Send 100 pkts ...
>>> | * Rate 10mbit ...
>>> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>> | | * Send 100 pkts ...
>>> | | * Rate 10mbit ...
>>> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | | | * Send 100 pkts ...
>>> | | | * Rate 10mbit ...
>>> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | | | | * Send 100 pkts ...
>>> | | | | * Rate 10mbit ...
>> ^ these are confusing IMHO, rest looks good to me
>>
>> Marcelo
>>
>
>
> Yes, just fixed it to :
Cool
> +---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
> |
> +---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | |
> | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
> |
> +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
> +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> * Send 100 pkts ...
> * Rate 10mbit ...
>
> I am not sure about the better format to print stats - use '*' or '>' as
> prefix, '*' - seems better ?
TBH I don't think we need one in there. It's already linked to the items
due to the tree on them. If you just align them to start right where the
the first word after the ')' begins, it would be good. Like:
| +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | Send 100 pkts ...
| | | Rate 10mbit ...
| | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb
cburst 1599b
| | | Send 100 pkts ...
| | | Rate 10mbit ...
| | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb
cburst 1599b
But I don't know how large this will get..
Yet I don't mind having one marker in there. Let's see what others think
about it.
Regards,
Marcelo
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Vadim Kochan @ 2014-12-18 12:23 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Vadim Kochan, Stephen Hemminger, netdev
In-Reply-To: <5492C7FD.8060603@gmail.com>
On Thu, Dec 18, 2014 at 10:26:37AM -0200, Marcelo Ricardo Leitner wrote:
> >+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | * Send 100 pkts ...
> > | * Rate 10mbit ...
> > +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> > | | * Send 100 pkts ...
> > | | * Rate 10mbit ...
> > | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | | * Send 100 pkts ...
> > | | | * Rate 10mbit ...
> > | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | | | * Send 100 pkts ...
> > | | | | * Rate 10mbit ...
> ^ these are confusing IMHO, rest looks good to me
>
> Marcelo
>
Yes, just fixed it to :
+---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
|
+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
+---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| |
| +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
|
+---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
+---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
* Send 100 pkts ...
* Rate 10mbit ...
I am not sure about the better format to print stats - use '*' or '>' as
prefix, '*' - seems better ?
Regards,
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Marcelo Ricardo Leitner @ 2014-12-18 12:26 UTC (permalink / raw)
To: Vadim Kochan; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20141218031257.GA19527@angus-think.lan>
On 18-12-2014 01:12, Vadim Kochan wrote:
> On Wed, Dec 17, 2014 at 11:56:04PM -0200, Marcelo Ricardo Leitner wrote:
>> On 17-12-2014 21:56, Vadim Kochan wrote:
>>> On Wed, Dec 17, 2014 at 11:55:35AM -0800, Stephen Hemminger wrote:
>>>> On Tue, 16 Dec 2014 16:12:41 -0200
>>>> Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
>>>>
>>>>> On 15-12-2014 20:48, vadim4j@gmail.com wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I am playing with showing classes in more hierarchically format and I
>>>>>> have some code and example of output from my TC looks like:
>>>>>>
>>>>>> # tc/tc -t class show dev tap0
>>>>>>
>>>>>> \---1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:10 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:11 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:111 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:20 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> \---1:30 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>>
>>>>>>
>>>>>> which in standart output mode it looks like:
>>>>>>
>>>>>> # tc/tc class show dev tap0
>>>>>>
>>>>>> class htb 1:11 parent 1:10 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:111 parent 1:11 prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:10 parent 1:1 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>>>>> class htb 1:1 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:20 parent 1:1 leaf 20: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:2 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:30 parent 1:1 leaf 30: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:40 parent 1:2 leaf 40: prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>>>>> class htb 1:50 parent 1:2 leaf 50: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>> class htb 1:60 parent 1:2 leaf 60: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>>>
>>>>>> So I'd like to ask if it might be useful for the TC users (may be
>>>>>> better format ?) to have this ?
>>>>>
>>>>> Good idea! It already looks good, but what about:
>>>>>
>>>>> |-- 1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>> | |-- 1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>> | |-- 1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>> | '-- 1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>> |-- 1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>> ...
>>>>>
>>>>> just another idea..
>>>>>
>>>>> Thanks.
>>>>> Marcelo
>>>>
>>>> There are several places that also print tree format, hopefully there would
>>>> be reusable code (lspci, tree, ps).
>>>>
>>>
>>> OK, currently I have the following output:
>>>
>>> +---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>> | +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> |
>>> +---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | |
>>> | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> |
>>> +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>> +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>
>>> How about this ?
>>
>> Looks very good to me, thanks!
>>
>>> Regards,
>>> Vadim Kochan
>>>
>>
>
> There is an exampe output of tree with stats:
>
> +---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> |
> +---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | | * Send 100 pkts ...
> | | | | * Rate 10mbit ...
^ these are confusing IMHO, rest looks good to me
Marcelo
> | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | | * Send 100 pkts ...
> | | | * Rate 10mbit ...
> | |
> | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> |
> +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | * Send 100 pkts ...
> | | * Rate 10mbit ...
> +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | * Send 100 pkts ...
> | * Rate 10mbit ...
>
>
> Yeah, this is bigger one ...
>
> Regards,
> --
> 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
>
^ permalink raw reply
* [PATCH net] be2net: Fix incorrect setting of tunnel offload flag in netdev features
From: Sriharsha Basavapatna @ 2014-12-19 4:30 UTC (permalink / raw)
To: netdev
An earlier commit to resolve an issue with encapsulation offloads missed
setting a bit in the outer netdev features flag. This results in loss of TSO
feature on a VxLAN interface.
Fixes: 630f4b70 ("Export tunnel offloads only when a VxLAN tunnel is created")
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2aacd47..1960731 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3138,6 +3138,7 @@ static void be_disable_vxlan_offloads(struct be_adapter *adapter)
netdev->hw_enc_features = 0;
netdev->hw_features &= ~(NETIF_F_GSO_UDP_TUNNEL);
+ netdev->features &= ~(NETIF_F_GSO_UDP_TUNNEL);
}
#endif
@@ -4429,6 +4430,7 @@ static void be_add_vxlan_port(struct net_device *netdev, sa_family_t sa_family,
NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_GSO_UDP_TUNNEL;
netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
+ netdev->features |= NETIF_F_GSO_UDP_TUNNEL;
dev_info(dev, "Enabled VxLAN offloads for UDP port %d\n",
be16_to_cpu(port));
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: Wei Liu @ 2014-12-18 11:51 UTC (permalink / raw)
To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
On Thu, Dec 18, 2014 at 11:13:06AM +0000, David Vrabel wrote:
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature. But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
>
> Netback sort of works as-is in this mode except:
>
> - If there are no Rx requests and the internal Rx queue fills, only
> the drain timeout will wake the thread. The default drain timeout
> of 10 s would give unacceptable pauses.
>
> - If an Rx stall was detected and the internal Rx queue is drained,
> then the Rx thread would never wake.
>
> Handle these two cases (when feature-rx-notify is disabled) by:
>
> - Reducing the drain timeout to 30 ms.
>
> - Disabling Rx stall detection.
>
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Thomas Graf @ 2014-12-18 11:41 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Jiri Pirko,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AD7B82@IRSMSX108.ger.corp.intel.com>
On 12/18/14 at 11:29am, Varlese, Marco wrote:
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index f7d0d2d..19cb51a 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -146,6 +146,7 @@ enum {
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> IFLA_PHYS_SWITCH_ID,
> + IFLA_SWITCH_PORT_CFG,
> __IFLA_MAX
> };
Needs an entry in ifla_policy[]
[IFLA_SWITCH_PORT_CFG] = { .type = NLA_NESTED },
> @@ -603,4 +604,18 @@ enum {
>
> #define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
>
> +/* Switch Port Attributes section */
> +
> +enum {
> + IFLA_ATTR_UNSPEC,
> + IFLA_ATTR_LEARNING,
> + IFLA_ATTR_LOOPBACK,
> + IFLA_ATTR_BCAST_FLOODING,
> + IFLA_ATTR_UCAST_FLOODING,
> + IFLA_ATTR_MCAST_FLOODING,
> + __IFLA_ATTR_MAX
> +};
> +
> +#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
Change the prefix to IFLA_SW_* since it's switch specific?
>
> +#ifdef CONFIG_NET_SWITCHDEV
> +static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
> +{
> + int rem, err = -EINVAL;
> + struct nlattr *v;
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + nla_for_each_nested(v, attr, rem) {
> + u32 op = nla_type(v);
> + u64 value = 0;
> +
> + switch (op) {
> + case IFLA_ATTR_LEARNING:
> + case IFLA_ATTR_LOOPBACK:
> + case IFLA_ATTR_BCAST_FLOODING:
> + case IFLA_ATTR_UCAST_FLOODING:
> + case IFLA_ATTR_MCAST_FLOODING: {
> + if (nla_len(v) < sizeof(value)) {
> + err = -EINVAL;
> + break;
> + }
You should validate the message before you start applying the
changes. Otherwise if the 3rd attribute is too short you've already
applied some changes and the user has not idea how much has been
applied.
nla_parse_nested() can help here.
> +
> + value = nla_get_u64(v);
> + err = ops->ndo_switch_port_set_cfg(dev,
> + op,
> + value);
This avoids having individual ndos but wastes a lot of space in the
Netlink message. Not a problem when setting configuration but you
likely want to dump these attributes as well and we need 12 bytes
for each attribute even though some are merely flags which could fit
in 4 bytes.
> static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
> {
> int rem, err = -EINVAL;
> @@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
> status |= DO_SETLINK_NOTIFY;
> }
> }
> +#ifdef CONFIG_NET_SWITCHDEV
> + if (tb[IFLA_SWITCH_PORT_CFG]) {
> + err = -EOPNOTSUPP;
> + if (!ops->ndo_switch_port_set_cfg)
> + goto errout;
> + if (!ops->ndo_switch_parent_id_get)
> + goto errout;
> + err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
> + if (err < 0)
> + goto errout;
> +
> + status |= DO_SETLINK_NOTIFY;
> + }
> +#endif
Should return -EOPNOTSUPP if IFLA_SWITCH_PORT_CFG is provided but
CONFIG_NET_SWITCHDEV is not set.
^ permalink raw reply
* [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-18 11:29 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Fastabend, John R, Thomas Graf, Jiri Pirko,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
From: Marco Varlese <marco.varlese@intel.com>
Switch hardware offers a list of attributes that are configurable
on a per port basis.
This patch provides a mechanism to configure switch ports by adding
an NDO for setting specific values to specific attributes.
There will be a separate patch that adds the "get" functionality via
another NDO and another patch that extends iproute2 to call the two
new NDOs.
Signed-off-by: Marco Varlese <marco.varlese@intel.com>
---
include/linux/netdevice.h | 5 ++++
include/uapi/linux/if_link.h | 15 ++++++++++++
net/core/rtnetlink.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d..4881c7b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
* int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
* Called to notify switch device port of bridge port STP
* state change.
+ * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ * u32 attr, u64 value);
+ * Called to set specific switch ports attributes.
*/
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
@@ -1185,6 +1188,8 @@ struct net_device_ops {
struct netdev_phys_item_id *psid);
int (*ndo_switch_port_stp_update)(struct net_device *dev,
u8 state);
+ int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ u32 attr, u64 value);
#endif
};
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index f7d0d2d..19cb51a 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -146,6 +146,7 @@ enum {
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
IFLA_PHYS_SWITCH_ID,
+ IFLA_SWITCH_PORT_CFG,
__IFLA_MAX
};
@@ -603,4 +604,18 @@ enum {
#define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
+/* Switch Port Attributes section */
+
+enum {
+ IFLA_ATTR_UNSPEC,
+ IFLA_ATTR_LEARNING,
+ IFLA_ATTR_LOOPBACK,
+ IFLA_ATTR_BCAST_FLOODING,
+ IFLA_ATTR_UCAST_FLOODING,
+ IFLA_ATTR_MCAST_FLOODING,
+ __IFLA_ATTR_MAX
+};
+
+#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
+
#endif /* _UAPI_LINUX_IF_LINK_H */
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index eaa057f..c0d1c45 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1389,6 +1389,46 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
return 0;
}
+#ifdef CONFIG_NET_SWITCHDEV
+static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
+{
+ int rem, err = -EINVAL;
+ struct nlattr *v;
+ const struct net_device_ops *ops = dev->netdev_ops;
+
+ nla_for_each_nested(v, attr, rem) {
+ u32 op = nla_type(v);
+ u64 value = 0;
+
+ switch (op) {
+ case IFLA_ATTR_LEARNING:
+ case IFLA_ATTR_LOOPBACK:
+ case IFLA_ATTR_BCAST_FLOODING:
+ case IFLA_ATTR_UCAST_FLOODING:
+ case IFLA_ATTR_MCAST_FLOODING: {
+ if (nla_len(v) < sizeof(value)) {
+ err = -EINVAL;
+ break;
+ }
+
+ value = nla_get_u64(v);
+ err = ops->ndo_switch_port_set_cfg(dev,
+ op,
+ value);
+ break;
+ }
+ default:
+ err = -EINVAL;
+ break;
+ }
+ if (err)
+ break;
+ }
+ return err;
+}
+
+#endif
+
static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
{
int rem, err = -EINVAL;
@@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
status |= DO_SETLINK_NOTIFY;
}
}
+#ifdef CONFIG_NET_SWITCHDEV
+ if (tb[IFLA_SWITCH_PORT_CFG]) {
+ err = -EOPNOTSUPP;
+ if (!ops->ndo_switch_port_set_cfg)
+ goto errout;
+ if (!ops->ndo_switch_parent_id_get)
+ goto errout;
+ err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
+ if (err < 0)
+ goto errout;
+
+ status |= DO_SETLINK_NOTIFY;
+ }
+#endif
err = 0;
errout:
--
1.8.5.3
^ permalink raw reply related
* [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: David Vrabel @ 2014-12-18 11:13 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature. But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.
Netback sort of works as-is in this mode except:
- If there are no Rx requests and the internal Rx queue fills, only
the drain timeout will wake the thread. The default drain timeout
of 10 s would give unacceptable pauses.
- If an Rx stall was detected and the internal Rx queue is drained,
then the Rx thread would never wake.
Handle these two cases (when feature-rx-notify is disabled) by:
- Reducing the drain timeout to 30 ms.
- Disabling Rx stall detection.
Reported-by: John <jw@nuclearfallout.net>
Tested-by: John <jw@nuclearfallout.net>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/common.h | 4 +++-
drivers/net/xen-netback/interface.c | 4 +++-
drivers/net/xen-netback/netback.c | 27 ++++++++++++++-------------
drivers/net/xen-netback/xenbus.c | 12 +++++++++---
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
*/
bool disabled;
unsigned long status;
+ unsigned long drain_timeout;
+ unsigned long stall_timeout;
/* Queues */
struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
extern bool separate_tx_rx_irq;
extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
extern unsigned int xenvif_max_queues;
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
cb = XENVIF_RX_CB(skb);
- cb->expires = jiffies + rx_drain_timeout_jiffies;
+ cb->expires = jiffies + vif->drain_timeout;
xenvif_rx_queue_tail(queue, skb);
xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
vif->ip_csum = 1;
vif->dev = dev;
vif->disabled = false;
+ vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+ vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
/* Start out with no queues. */
vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..908e65e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
*/
unsigned int rx_drain_timeout_msecs = 10000;
module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
/* The length of time before the frontend is considered unresponsive
* because it isn't providing Rx slots.
*/
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
unsigned int xenvif_max_queues;
module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
return !queue->stalled
&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
&& time_after(jiffies,
- queue->last_rx_time + rx_stall_timeout_jiffies);
+ queue->last_rx_time + queue->vif->stall_timeout);
}
static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
{
return (!skb_queue_empty(&queue->rx_queue)
&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
- || xenvif_rx_queue_stalled(queue)
- || xenvif_rx_queue_ready(queue)
+ || (queue->vif->stall_timeout &&
+ (xenvif_rx_queue_stalled(queue)
+ || xenvif_rx_queue_ready(queue)))
|| kthread_should_stop()
|| queue->vif->disabled;
}
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
struct xenvif_queue *queue = data;
struct xenvif *vif = queue->vif;
+ if (!vif->stall_timeout)
+ xenvif_queue_carrier_on(queue);
+
for (;;) {
xenvif_wait_for_rx_work(queue);
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
* while it's probably not responsive, drop the
* carrier so packets are dropped earlier.
*/
- if (xenvif_rx_queue_stalled(queue))
- xenvif_queue_carrier_off(queue);
- else if (xenvif_rx_queue_ready(queue))
- xenvif_queue_carrier_on(queue);
+ if (vif->stall_timeout) {
+ if (xenvif_rx_queue_stalled(queue))
+ xenvif_queue_carrier_off(queue);
+ else if (xenvif_rx_queue_ready(queue))
+ xenvif_queue_carrier_on(queue);
+ }
/* Queued packets may have foreign pages from other
* domains. These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
if (rc)
goto failed_init;
- rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
- rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
#ifdef CONFIG_DEBUG_FS
xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
return -EOPNOTSUPP;
if (xenbus_scanf(XBT_NIL, dev->otherend,
- "feature-rx-notify", "%d", &val) < 0 || val == 0) {
- xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
- return -EINVAL;
+ "feature-rx-notify", "%d", &val) < 0)
+ val = 0;
+ if (!val) {
+ /* - Reduce drain timeout to poll more frequently for
+ * Rx requests.
+ * - Disable Rx stall detection.
+ */
+ be->vif->drain_timeout = msecs_to_jiffies(30);
+ be->vif->stall_timeout = 0;
}
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
--
1.7.10.4
^ permalink raw reply related
* [PULL] vhost: cleanups and fixes
From: Michael S. Tsirkin @ 2014-12-18 10:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: herbert, kvm, mst, netdev, linux-kernel, virtualization
The following changes since commit f01a2a811ae04124fc9382925038fcbbd2f0b7c8:
virtio_ccw: finalize_features error handling (2014-12-09 21:42:06 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to 5ff16110c637726111662c1df41afd9df7ef36bd:
virtio_pci: restore module attributes (2014-12-17 00:59:40 +0200)
----------------------------------------------------------------
vhost/virtio: virtio 1.0 related fixes
Most importantly, this fixes using virtio_pci as a module.
Further, the big virtio 1.0 conversion missed a couple of places. This fixes
them up.
This isn't 100% sparse-clean yet because on many architectures get_user
triggers sparse warnings when used with __bitwise tag (when same tag is on both
pointer and value read).
I posted a patchset to fix it up by adding __force on all
arches that don't already have it (many do), when that's
merged these warnings will go away.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Herbert Xu (1):
virtio_pci: restore module attributes
Michael S. Tsirkin (15):
virtio: set VIRTIO_CONFIG_S_FEATURES_OK on restore
virtio_config: fix virtio_cread_bytes
virtio_pci_common.h: drop VIRTIO_PCI_NO_LEGACY
virtio_pci: move probe to common file
virtio_pci: add VIRTIO_PCI_NO_LEGACY
virtio: core support for config generation
tools/virtio: more stubs
tools/virtio: fix vringh test
tools/virtio: 64 bit features
tools/virtio: enable -Werror
tools/virtio: add virtio 1.0 in virtio_test
tools/virtio: add virtio 1.0 in vringh_test
vringh: 64 bit features
vringh: update for virtio 1.0 APIs
mic/host: fix up virtio 1.0 APIs
drivers/virtio/virtio_pci_common.h | 7 +-
include/linux/virtio_config.h | 29 +++++++-
include/linux/vringh.h | 37 +++++++++-
include/uapi/linux/virtio_pci.h | 15 ++--
tools/virtio/linux/virtio.h | 1 +
tools/virtio/linux/virtio_byteorder.h | 8 +++
tools/virtio/linux/virtio_config.h | 70 +++++++++++++++++-
tools/virtio/uapi/linux/virtio_types.h | 1 +
drivers/misc/mic/host/mic_debugfs.c | 18 +++--
drivers/vhost/vringh.c | 125 ++++++++++++++++++++-------------
drivers/virtio/virtio.c | 37 ++++++----
drivers/virtio/virtio_pci_common.c | 39 +++++++++-
drivers/virtio/virtio_pci_legacy.c | 24 +------
tools/virtio/virtio_test.c | 15 +++-
tools/virtio/vringh_test.c | 5 +-
tools/virtio/Makefile | 2 +-
16 files changed, 324 insertions(+), 109 deletions(-)
create mode 100644 tools/virtio/linux/virtio_byteorder.h
create mode 100644 tools/virtio/uapi/linux/virtio_types.h
^ permalink raw reply
* [PATCH net] netlink: Don't reorder loads/stores before marking mmap netlink frame as available
From: Thomas Graf @ 2014-12-18 10:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, dborkman, luto, torvalds, kaber, netdev
In-Reply-To: <1418774579.9773.69.camel@edumazet-glaptop2.roam.corp.google.com>
Each mmap Netlink frame contains a status field which indicates
whether the frame is unused, reserved, contains data or needs to
be skipped. Both loads and stores may not be reordeded and must
complete before the status field is changed and another CPU might
pick up the frame for use. Use an smp_mb() to cover needs of both
types of callers to netlink_set_status(), callers which have been
reading data frame from the frame, and callers which have been
filling or releasing and thus writing to the frame.
- Example code path requiring a smp_rmb():
memcpy(skb->data, (void *)hdr + NL_MMAP_HDRLEN, hdr->nm_len);
netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED);
- Example code path requiring a smp_wmb():
hdr->nm_uid = from_kuid(sk_user_ns(sk), NETLINK_CB(skb).creds.uid);
hdr->nm_gid = from_kgid(sk_user_ns(sk), NETLINK_CB(skb).creds.gid);
netlink_frame_flush_dcache(hdr);
netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
Fixes: f9c228 ("netlink: implement memory mapped recvmsg()")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index ef5f77b..2662821 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -550,9 +550,9 @@ static enum nl_mmap_status netlink_get_status(const struct nl_mmap_hdr *hdr)
static void netlink_set_status(struct nl_mmap_hdr *hdr,
enum nl_mmap_status status)
{
+ smp_mb();
hdr->nm_status = status;
flush_dcache_page(pgvec_to_page(hdr));
- smp_wmb();
}
static struct nl_mmap_hdr *
^ permalink raw reply related
* [PATCH net] enic: fix rx skb checksum
From: Govindarajulu Varadarajan @ 2014-12-18 10:28 UTC (permalink / raw)
To: davem, netdev, ssujith, benve
Cc: Govindarajulu Varadarajan, Jiri Benc, Stefan Assmann
Hardware always provides compliment of IP pseudo checksum. Stack expects
whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.
This causes checksum error in nf & ovs.
kernel: qg-19546f09-f2: hw csum failure
kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1
kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
kernel: Call Trace:
kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b
kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380
Hardware verifies IP & tcp/udp header checksum but does not provide payload
checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stefan Assmann <sassmann@redhat.com>
Reported-by: Sunil Choudhary <schoudha@redhat.com>
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 868d0f6..705f334 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1060,10 +1060,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
PKT_HASH_TYPE_L4 : PKT_HASH_TYPE_L3);
}
- if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
- skb->csum = htons(checksum);
- skb->ip_summed = CHECKSUM_COMPLETE;
- }
+ /* Hardware does not provide whole packet checksum. It only
+ * provides pseudo checksum. Since hw validates the packet
+ * checksum but not provide us the checksum value. use
+ * CHECSUM_UNNECESSARY.
+ */
+ if ((netdev->features & NETIF_F_RXCSUM) && tcp_udp_csum_ok &&
+ ipv4_csum_ok)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
if (vlan_stripped)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tci);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto @ 2014-12-18 9:47 UTC (permalink / raw)
To: Alexander Duyck, e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org, Choi, Sy Jong, Hayato Momma,
linux-kernel@vger.kernel.org
In-Reply-To: <54809D57.9060804@gmail.com>
> > > Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
> > >
> > > On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
> > > > From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> > > >
> > > > The limitation of the number of multicast address for VF is not enough
> > > > for the large scale server with SR-IOV feature.
> > > > IPv6 requires the multicast MAC address for each IP address to handle
> > > > the Neighbor Solicitation message.
> > > > We couldn't assign over 30 IPv6 addresses to a single VF interface.
> > > >
> > > > The easy way to solve this is enabling multicast promiscuous mode.
> > > > It is good to have a functionality to enable multicast promiscuous mode
> > > > for each VF from VF driver.
> > > >
> > > > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> > > > enable/disable multicast promiscuous mode in VF. If multicast promiscuous
> > > > mode is enabled the VF can receive all multicast packets.
> > > >
> > > > With this patch, the ixgbevf driver automatically enable multicast
> > > > promiscuous mode when the number of multicast addresses is over than 30
> > > > if possible.
> > > >
> > > > This also bump the API version up to 1.2 to check whether the API,
> > > > IXGBE_VF_SET_MC_PROMISC is available.
> > > >
> > > > Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> > > > CC: Choi, Sy Jong <sy.jong.choi@intel.com>
> > > > Reviewed-by: Hayato Momma <h-momma@ce.jp.nec.com>
> > >
> > > This is a REALLY bad idea unless you plan to limit this to privileged VFs.
> > >
> > > I would recommend looking at adding an ndo operation to control this
> > > feature so that it could be disabled by default in the PF and only
> > > enabled on the host side if specifically requested. Otherwise the
Do you think whether introducing ndo_set_vf_mc_promisc to control the multicast
promiscuous mode of VF from host is good to you?
If that's okay I'm fine to post the new patch.
We need the capability to use thousands IPv6 addresses in VF.
I think setting multicast promiscuous mode on is the easiest way to do it.
thanks,
Hiroshi
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH net] bnx2x: fix typos in "configure"
From: Jiri Benc @ 2014-12-18 8:04 UTC (permalink / raw)
To: netdev; +Cc: Ariel Elior
Noticed when debugging ptp.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 691f0bf09ee1..9f5e38769a29 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13256,7 +13256,7 @@ static int bnx2x_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
return -EFAULT;
}
- DP(BNX2X_MSG_PTP, "Configrued val = %d, period = %d\n", best_val,
+ DP(BNX2X_MSG_PTP, "Configured val = %d, period = %d\n", best_val,
best_period);
return 0;
@@ -14784,7 +14784,7 @@ static int bnx2x_hwtstamp_ioctl(struct bnx2x *bp, struct ifreq *ifr)
-EFAULT : 0;
}
-/* Configrues HW for PTP */
+/* Configures HW for PTP */
static int bnx2x_configure_ptp(struct bnx2x *bp)
{
int rc, port = BP_PORT(bp);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
index b0779d773343..6fe547c93e74 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
@@ -7549,7 +7549,7 @@ Theotherbitsarereservedandshouldbezero*/
#define IGU_REG_SISR_MDPC_WOMASK_UPPER 0x05a6
#define IGU_REG_RESERVED_UPPER 0x05ff
-/* Fields of IGU PF CONFIGRATION REGISTER */
+/* Fields of IGU PF CONFIGURATION REGISTER */
#define IGU_PF_CONF_FUNC_EN (0x1<<0) /* function enable */
#define IGU_PF_CONF_MSI_MSIX_EN (0x1<<1) /* MSI/MSIX enable */
#define IGU_PF_CONF_INT_LINE_EN (0x1<<2) /* INT enable */
@@ -7557,7 +7557,7 @@ Theotherbitsarereservedandshouldbezero*/
#define IGU_PF_CONF_SINGLE_ISR_EN (0x1<<4) /* single ISR mode enable */
#define IGU_PF_CONF_SIMD_MODE (0x1<<5) /* simd all ones mode */
-/* Fields of IGU VF CONFIGRATION REGISTER */
+/* Fields of IGU VF CONFIGURATION REGISTER */
#define IGU_VF_CONF_FUNC_EN (0x1<<0) /* function enable */
#define IGU_VF_CONF_MSI_MSIX_EN (0x1<<1) /* MSI/MSIX enable */
#define IGU_VF_CONF_PARENT_MASK (0x3<<2) /* Parent PF */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 09/10] macvtap: Re-enable UFO support
From: Michael S. Tsirkin @ 2014-12-18 7:55 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, Vladislav Yasevich, ben, stefanha, virtualization
In-Reply-To: <54923F67.3000205@redhat.com>
On Wed, Dec 17, 2014 at 09:43:51PM -0500, Vlad Yasevich wrote:
> On 12/17/2014 05:41 PM, Michael S. Tsirkin wrote:
> > On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote:
> >> Now that UFO is split into v4 and v6 parts, we can bring
> >> back v4 support. Continue to handle legacy applications
> >> by selecting the ipv6 fagment id but do not change the
> >> gso type. This allows 2 legacy VMs to continue to communicate.
> >>
> >> Based on original work from Ben Hutchings.
> >>
> >> Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")
> >> CC: Ben Hutchings <ben@decadent.org.uk>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> drivers/net/macvtap.c | 20 ++++++++++++++------
> >> 1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> >> index 880cc09..75febd4 100644
> >> --- a/drivers/net/macvtap.c
> >> +++ b/drivers/net/macvtap.c
> >> @@ -66,7 +66,7 @@ static struct cdev macvtap_cdev;
> >> static const struct proto_ops macvtap_socket_ops;
> >>
> >> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
> >> - NETIF_F_TSO6)
> >> + NETIF_F_TSO6 | NETIF_F_UFO)
> >> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
> >> #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
> >>
> >> @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb,
> >> gso_type = SKB_GSO_TCPV6;
> >> break;
> >> case VIRTIO_NET_HDR_GSO_UDP:
> >> - pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
> >> - current->comm);
> >> gso_type = SKB_GSO_UDP;
> >> - if (skb->protocol == htons(ETH_P_IPV6))
> >> + if (vlan_get_protocol(skb) == htons(ETH_P_IPV6)) {
> >> + /* This is to support legacy appliacations.
> >> + * Do not change the gso_type as legacy apps
> >> + * may not know about the new type.
> >> + */
> >> ipv6_proxy_select_ident(skb);
> >> + }
> >> break;
> >> default:
> >> return -EINVAL;
> >> @@ -619,6 +622,8 @@ static void macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
> >> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
> >> else if (sinfo->gso_type & SKB_GSO_TCPV6)
> >> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
> >> + else if (sinfo->gso_type & SKB_GSO_UDP)
> >> + vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
> >> else
> >> BUG();
> >> if (sinfo->gso_type & SKB_GSO_TCP_ECN)
> >> @@ -955,6 +960,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
> >> if (arg & TUN_F_TSO6)
> >> feature_mask |= NETIF_F_TSO6;
> >> }
> >> +
> >> + if (arg & TUN_F_UFO)
> >> + feature_mask |= NETIF_F_UFO;
> >> }
> >>
> >> /* tun/tap driver inverts the usage for TSO offloads, where
> >> @@ -965,7 +973,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
> >> * When user space turns off TSO, we turn off GSO/LRO so that
> >> * user-space will not receive TSO frames.
> >> */
> >> - if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
> >> + if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
> >> features |= RX_OFFLOADS;
> >> else
> >> features &= ~RX_OFFLOADS;
> >
> > By the way this logic is completely broken, even without your patch,
> > isn't it?
> >
> > It says: enable LRO+GRO if any of NETIF_F_TSO | NETIF_F_TSO6 |
> > NETIF_F_UFO set.
> >
> > So what happens if I enable TSO only?
> > LRO gets enabled so I can still get TSO6 packets.
> >
> >
> > This really should be:
> >
> > if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO) ==
> > (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO)
> >
> >
> > fixing this probably should be a separate patch before your
> > series, and Cc stable.
>
> Actually, all this LRO/GRO feature manipulation on the macvtap device is
> rather pointless as those features aren't really checked at any point
> on the macvtap receive path. GRO calls are done from napi context on
> the lowest device, so by the time a packet hits macvtap, GRO/LRO has
> already been done.
>
> So it doesn't really matter that we disable them incorrectly. I
> can send a separate patch to clean this up.
Hmm so if userspace says it can't handle TSO packets,
it might get them anyway?
> >
> >
> >> @@ -1066,7 +1074,7 @@ static long macvtap_ioctl(struct file *file, unsigned int cmd,
> >> case TUNSETOFFLOAD:
> >> /* let the user check for future flags */
> >> if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> >> - TUN_F_TSO_ECN))
> >> + TUN_F_TSO_ECN | TUN_F_UFO))
> >> return -EINVAL;
> >>
> >> rtnl_lock();
> >> --
> >> 1.9.3
^ permalink raw reply
* Re: [PATCH 01/10] core: Split out UFO6 support
From: Michael S. Tsirkin @ 2014-12-18 7:54 UTC (permalink / raw)
To: Vlad Yasevich
Cc: netdev, Vladislav Yasevich, virtualization, stefanha, ben,
David Miller
In-Reply-To: <54921266.30300@redhat.com>
Cc Dave, pls remember to do this next time otherwise
your patches won't get merged :)
On Wed, Dec 17, 2014 at 06:31:50PM -0500, Vlad Yasevich wrote:
> On 12/17/2014 05:45 PM, Michael S. Tsirkin wrote:
> > On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote:
> >> Split IPv6 support for UFO into its own feature similiar to TSO.
> >> This will later allow us to re-enable UFO support for virtio-net
> >> devices.
> >>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> include/linux/netdev_features.h | 7 +++++--
> >> include/linux/netdevice.h | 1 +
> >> include/linux/skbuff.h | 1 +
> >> net/core/dev.c | 35 +++++++++++++++++++----------------
> >> net/core/ethtool.c | 2 +-
> >> 5 files changed, 27 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> >> index dcfdecb..a078945 100644
> >> --- a/include/linux/netdev_features.h
> >> +++ b/include/linux/netdev_features.h
> >> @@ -48,8 +48,9 @@ enum {
> >> NETIF_F_GSO_UDP_TUNNEL_BIT, /* ... UDP TUNNEL with TSO */
> >> NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT,/* ... UDP TUNNEL with TSO & CSUM */
> >> NETIF_F_GSO_MPLS_BIT, /* ... MPLS segmentation */
> >> + NETIF_F_UFO6_BIT, /* ... UDPv6 fragmentation */
> >> /**/NETIF_F_GSO_LAST = /* last bit, see GSO_MASK */
> >> - NETIF_F_GSO_MPLS_BIT,
> >> + NETIF_F_UFO6_BIT,
> >>
> >> NETIF_F_FCOE_CRC_BIT, /* FCoE CRC32 */
> >> NETIF_F_SCTP_CSUM_BIT, /* SCTP checksum offload */
> >> @@ -109,6 +110,7 @@ enum {
> >> #define NETIF_F_TSO_ECN __NETIF_F(TSO_ECN)
> >> #define NETIF_F_TSO __NETIF_F(TSO)
> >> #define NETIF_F_UFO __NETIF_F(UFO)
> >> +#define NETIF_F_UFO6 __NETIF_F(UFO6)
> >> #define NETIF_F_VLAN_CHALLENGED __NETIF_F(VLAN_CHALLENGED)
> >> #define NETIF_F_RXFCS __NETIF_F(RXFCS)
> >> #define NETIF_F_RXALL __NETIF_F(RXALL)
> >> @@ -141,7 +143,7 @@ enum {
> >>
> >> /* List of features with software fallbacks. */
> >> #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
> >> - NETIF_F_TSO6 | NETIF_F_UFO)
> >> + NETIF_F_TSO6 | NETIF_F_UFO | NETIF_F_UFO6)
> >>
> >> #define NETIF_F_GEN_CSUM NETIF_F_HW_CSUM
> >> #define NETIF_F_V4_CSUM (NETIF_F_GEN_CSUM | NETIF_F_IP_CSUM)
> >> @@ -149,6 +151,7 @@ enum {
> >> #define NETIF_F_ALL_CSUM (NETIF_F_V4_CSUM | NETIF_F_V6_CSUM)
> >>
> >> #define NETIF_F_ALL_TSO (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_TSO_ECN)
> >> +#define NETIF_F_ALL_UFO (NETIF_F_UFO | NETIF_F_UFO6)
> >>
> >> #define NETIF_F_ALL_FCOE (NETIF_F_FCOE_CRC | NETIF_F_FCOE_MTU | \
> >> NETIF_F_FSO)
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 74fd5d3..86af10a 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> >> @@ -3559,6 +3559,7 @@ static inline bool net_gso_ok(netdev_features_t features, int gso_type)
> >> /* check flags correspondence */
> >> BUILD_BUG_ON(SKB_GSO_TCPV4 != (NETIF_F_TSO >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_UDP != (NETIF_F_UFO >> NETIF_F_GSO_SHIFT));
> >> + BUILD_BUG_ON(SKB_GSO_UDP6 != (NETIF_F_UFO6 >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_DODGY != (NETIF_F_GSO_ROBUST >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_TCP_ECN != (NETIF_F_TSO_ECN >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_TCPV6 != (NETIF_F_TSO6 >> NETIF_F_GSO_SHIFT));
> >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> >> index 6c8b6f6..8538b67 100644
> >> --- a/include/linux/skbuff.h
> >> +++ b/include/linux/skbuff.h
> >> @@ -372,6 +372,7 @@ enum {
> >>
> >> SKB_GSO_MPLS = 1 << 12,
> >>
> >> + SKB_GSO_UDP6 = 1 << 13
> >> };
> >>
> >> #if BITS_PER_LONG > 32
> >
> > So this implies anything getting GSO packets e.g.
> > from userspace now needs to check IP version to
> > set GSO type correctly.
> >
> > I think you missed some places that do this, e.g. af_packet
> > sockets.
> >
>
> I looked at af_packet sockets and they set this only in the event
> vnet header has been used with a GSO type. In this case, the user
> already knows the the type.
Imagine you are receiving a packet:
if (vnet_hdr.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
switch (vnet_hdr.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
case VIRTIO_NET_HDR_GSO_TCPV4:
gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_TCPV6:
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
gso_type = SKB_GSO_UDP;
break;
default:
goto out_unlock;
}
if (vnet_hdr.gso_type & VIRTIO_NET_HDR_GSO_ECN)
gso_type |= SKB_GSO_TCP_ECN;
if (vnet_hdr.gso_size == 0)
goto out_unlock;
}
we used to report UFO6 as SKB_GSO_UDP, we probably
should keep doing this, with your patch we select the
goto out_unlock path.
> It is true that with this series af_packets now can't do IPv6 UFO
> since there is no VIRTIO_NET_HDR_GSO_UDPV6 yet.
What do you mean by "do".
Are we talking about sending or receiving packets?
You seem to conflate the two.
We always discarded ID on RX.
For tun, this is xmit, so just by saying "this device can
not do UFO" you will never get short packets.
>
> I suppose we could do something similar there as we do in tun code/macvtap code.
> If that's the case, it currently broken as well.
>
> -vlad
Broken is a big word.
Let's stop conflating two directions.
Here's the way I look at it:
1. Userspace doesn't have a way to get fragment IDs
from tun/macvtap/packet sockets.
Presumably, not all users need these IDs.
E.g. old guests clearly don't.
We should either give them packets stripping the ID,
like we always did, or make sure they never get these packets.
Second option seems achievable for tun if we
never tell linux it can do UFO, but I don't see
how to do it for macvtap and packet socket.
2. Userspace doesn't have a way to set fragment IDs
for tun/macvtap/packet sockets.
Presumably, not all users have these IDs. E.g. old
guests clearly don't.
We should either generate our own ID,
like we always did, or make sure we don't accept
these packets.
Second option is almost sure to break userspace,
so it seems we must do the first one.
3.
Exactly the same two things if you replace userspace
with hypervisor and tun/macvtap/packet socket with
virtio device.
4.
As a next step, we should add a way for userspace
to tell us that it has ids and can handle them.
> >
> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> index 945bbd0..fa4d2ee 100644
> >> --- a/net/core/dev.c
> >> +++ b/net/core/dev.c
> >> @@ -5929,6 +5929,12 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
> >> features &= ~NETIF_F_ALL_TSO;
> >> }
> >>
> >> + /* UFO requires that SG is present as well */
> >> + if ((features & NETIF_F_ALL_UFO) && !(features & NETIF_F_SG)) {
> >> + netdev_dbg(dev, "Dropping UFO features since no SG feature.\n");
> >> + features &= ~NETIF_F_ALL_UFO;
> >> + }
> >> +
> >> if ((features & NETIF_F_TSO) && !(features & NETIF_F_HW_CSUM) &&
> >> !(features & NETIF_F_IP_CSUM)) {
> >> netdev_dbg(dev, "Dropping TSO features since no CSUM feature.\n");
> >> @@ -5952,24 +5958,21 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
> >> features &= ~NETIF_F_GSO;
> >> }
> >>
> >> - /* UFO needs SG and checksumming */
> >> - if (features & NETIF_F_UFO) {
> >> - /* maybe split UFO into V4 and V6? */
> >> - if (!((features & NETIF_F_GEN_CSUM) ||
> >> - (features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))
> >> - == (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
> >> - netdev_dbg(dev,
> >> - "Dropping NETIF_F_UFO since no checksum offload features.\n");
> >> - features &= ~NETIF_F_UFO;
> >> - }
> >> -
> >> - if (!(features & NETIF_F_SG)) {
> >> - netdev_dbg(dev,
> >> - "Dropping NETIF_F_UFO since no NETIF_F_SG feature.\n");
> >> - features &= ~NETIF_F_UFO;
> >> - }
> >> + /* UFO also needs checksumming */
> >> + if ((features & NETIF_F_UFO) && !(features & NETIF_F_GEN_CSUM) &&
> >> + !(features & NETIF_F_IP_CSUM)) {
> >> + netdev_dbg(dev,
> >> + "Dropping NETIF_F_UFO since no checksum offload features.\n");
> >> + features &= ~NETIF_F_UFO;
> >> + }
> >> + if ((features & NETIF_F_UFO6) && !(features & NETIF_F_GEN_CSUM) &&
> >> + !(features & NETIF_F_IPV6_CSUM)) {
> >> + netdev_dbg(dev,
> >> + "Dropping NETIF_F_UFO6 since no checksum offload features.\n");
> >> + features &= ~NETIF_F_UFO6;
> >> }
> >>
> >> +
> >> #ifdef CONFIG_NET_RX_BUSY_POLL
> >> if (dev->netdev_ops->ndo_busy_poll)
> >> features |= NETIF_F_BUSY_POLL;
> >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> >> index 06dfb29..93eff41 100644
> >> --- a/net/core/ethtool.c
> >> +++ b/net/core/ethtool.c
> >> @@ -223,7 +223,7 @@ static netdev_features_t ethtool_get_feature_mask(u32 eth_cmd)
> >> return NETIF_F_ALL_TSO;
> >> case ETHTOOL_GUFO:
> >> case ETHTOOL_SUFO:
> >> - return NETIF_F_UFO;
> >> + return NETIF_F_ALL_UFO;
> >> case ETHTOOL_GGSO:
> >> case ETHTOOL_SGSO:
> >> return NETIF_F_GSO;
> >> --
> >> 1.9.3
^ permalink raw reply
* Re: [PATCH] brcmsmac: don't leak kernel memory via printk()
From: Brian Norris @ 2014-12-18 6:32 UTC (permalink / raw)
To: John W. Linville, Kalle Valo, David S. Miller
Cc: Brian Norris, Brett Rudley, Arend van Spriel,
Franky (Zhenhui) Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list, netdev
In-Reply-To: <1418204358-8357-1-git-send-email-computersforpeace@gmail.com>
+ others [1]
On Wed, Dec 10, 2014 at 1:39 AM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Debug code prints the fifo name via custom dev_warn() wrappers. The
> fifo_names array is only non-zero when debugging is manually enabled,
> which is all well and good. However, it's *not* good that this array
> uses zero-length arrays in the non-debug case, and so it doesn't
> actually have any memory allocated to it. This means that as far as we
> know, fifo_names[i] actually points to garbage memory.
>
> I've seen this in my log:
>
> [ 4601.205511] brcmsmac bcma0:1: wl0: brcms_c_d11hdrs_mac80211: �GeL txop exceeded phylen 137/256 dur 1602/1504
>
> So let's give this array space enough to fill it with a NULL byte.
>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: brcm80211-dev-list@broadcom.com
> Cc: netdev@vger.kernel.org
BTW, I guess this qualifies as a security hole, albeit a small one.
Should this be CC: stable@vger.kernel.org?
> ---
> drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> index 1b474828d5b8..aed0c948dce8 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> @@ -316,7 +316,7 @@ static const u16 xmtfifo_sz[][NFIFO] = {
> static const char * const fifo_names[] = {
> "AC_BK", "AC_BE", "AC_VI", "AC_VO", "BCMC", "ATIM" };
> #else
> -static const char fifo_names[6][0];
> +static const char fifo_names[6][1];
> #endif
>
> #ifdef DEBUG
Brian
[1] http://lwn.net/Articles/626689/
^ permalink raw reply
* bugreport: Netdev watchdog timeout on wwan0 and soft lockup CPU #0, huawei E3276 modem always fails on GSM UDP up/downlink
From: Erik Alapää @ 2014-12-18 6:30 UTC (permalink / raw)
To: netdev
Disclaimer: This involves a mobile (cellular) (GSM/WCDMA/LTE) modem, but since
the crash involves netdev watchdog and a soft lockup of CPU #0 (see
trace below),
I post here. If doing so is not appropriate, I apologize beforehand.
Problem: up/dowlink UDP with iperf3 over GSM crashes Huawei E3276 USB
modem on 32-bit Debian-stable (wheezy) with 3.13 kernel and newer
kernels. Error also seen on 64-bit machines/Linux kernels.
Keywords: huawei_cdc_ncm, GSM, cdc-wdm, wwan0, netdev watchdog
Detailed problem description: Sending/receiving UDP 100+100kbit/s
up-and-downlink UDP traffic with 2 iperf3 processes over a Huawei
E3276 USB modem in GSM mode (GSM RAT) *always* fails after 3-15
minutes. Modem disconnects and kernel log shows 'NETDEV WATCHDOG:
wwan0 (huawei_cdc_ncm): transmit queue 0 timed out'. Also causes a soft
lockup of CPU #0.
Reproduced on a range of real and virtualized systems, all running Debian
or Kubuntu Linux with Linux kernel supporting the modem (3.13 and higher).
Output below is from a debian-jessie (unstable) system with custom-built dbg
kernel, but debian wheezy (stable) also reproduces same bug.
A clean way to reproduce is to use a clean debian wheezy install and
only adding iperf3 and a 3.16 kernel from debian-unstable.
At the end of this post I paste an excerpt from kern.log, if more logs
etc are needed I can provide them.
Command line of test application (showing uplink iperf UDP/GSM,
downlink is the same but with -R switch):
'./iperf3 -B <MODEM DHCP ADDR> -u -t 3600 -i 5 -p 5503 -b 100K -c <IP
ADDR OF IPERF SERVER>'
Distribution: debian-unstable
Kernel version: 3.16.7, vanilla debian unstable 3.17.0-trunk-686-pae,
3.17.2. All kernels that support the E3276 modem (kernels from 3.13
and upward) seem to fail.
Kernel modules: huawei_cdc_ncm, cdc_ncm, cdc_wdm, usb_wwan
Modem firmware version: 21.436.03.00.00
Lsusb showing modem/vendor id:
Bus 003 Device 027: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
LTE/UMTS/GSM Modem/Networkcard
Output of lsb_release -a:
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
Additional info: E3276 modem seems to be stable in Windows, so it may
be an issue with the huawei_cdc_ncm driver in Linux. But it may still
be a modem hw/firmware issue, and the netdev watchdog timeout on wwan0
could be caused by modem firmware crash. Modem also works much better
in Linux when using 3G (WCDMA) or 4G (LTE) instead of 2G (GSM).
Merry Christmas,
/Erik Alapää
Excerpt from kern.log:
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877612] ------------[ cut
here ]------------
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877647] WARNING: CPU: 0 PID:
0 at /build/linux-n7UL8Q/linux-3.17.4/net/sched/sch_generic.c:264
dev_watchdog+0x1ec/0x200()
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877649] NETDEV WATCHDOG:
wwan0 (huawei_cdc_ncm): transmit queue 0 timed out
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877650] Modules linked in:
huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep
binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd
fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm
usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event
snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq
snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon
ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul
ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx
shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys
vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg
ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common
crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore
usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata
scsi_mod [last unloaded: huawei_cdc_ncm]
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877768] CPU: 0 PID: 0 Comm:
swapper/0 Not tainted 3.17.0-trunk-686-pae #1 Debian 3.17.4-1~exp1
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877769] Hardware name:
VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform,
BIOS 6.00 07/31/2013
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877770] 00000000 de409ef4
c149bcff de409f04 c10598a8 c15d8868 de409f20 00000000
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877772] c15d88a4 00000108
c13de8bc 00000108 c13de8bc 00000009 db25b800 fff09a96
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877773] fffffb7e de409f0c
c10598f3 00000009 de409f04 c15d8868 de409f20 de409f40
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877775] Call Trace:
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877780] [<c149bcff>] ?
dump_stack+0x3e/0x4e
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877785] [<c10598a8>] ?
warn_slowpath_common+0x88/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877787] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877788] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877789] [<c10598f3>] ?
warn_slowpath_fmt+0x33/0x40
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877790] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877796] [<c10acb20>] ?
call_timer_fn+0x30/0x100
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877799] [<c108ccf7>] ?
__wake_up+0x37/0x50
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877801] [<c10a7a1f>] ?
rcu_report_qs_rnp+0xbf/0x100
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877802] [<c13de6d0>] ?
dev_graft_qdisc+0x70/0x70
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877804] [<c10ae476>] ?
run_timer_softirq+0x186/0x250
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877805] [<c13de6d0>] ?
dev_graft_qdisc+0x70/0x70
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877807] [<c105d43c>] ?
__do_softirq+0xec/0x240
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877809] [<c105d350>] ?
cpu_callback+0x180/0x180
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877844] [<c1011a06>] ?
do_softirq_own_stack+0x26/0x30
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877845] <IRQ> [<c105d705>]
? irq_exit+0x95/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877849] [<c14a2138>] ?
smp_apic_timer_interrupt+0x38/0x50
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877850] [<c14a187c>] ?
apic_timer_interrupt+0x34/0x3c
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877863] [<c104b822>] ?
native_safe_halt+0x2/0x10
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877866] [<c101873c>] ?
default_idle+0x1c/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877868] [<c1018ece>] ?
arch_cpu_idle+0xe/0x10
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877869] [<c108d653>] ?
cpu_startup_entry+0x303/0x340
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877871] [<c108cb6f>] ?
__wake_up_locked+0x1f/0x30
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877873] [<c16a5ab8>] ?
start_kernel+0x38d/0x393
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877874] ---[ end trace
07cf0823922200f7 ]---
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.939769] option1 ttyUSB0: GSM
modem (1-port) converter now disconnected from ttyUSB0
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.939779] option 2-1:1.0:
device disconnected
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.940770] option1 ttyUSB1: GSM
modem (1-port) converter now disconnected from ttyUSB1
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.940777] option 2-1:1.1:
device disconnected
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.941098] huawei_cdc_ncm
2-1:1.2 wwan0: unregister 'huawei_cdc_ncm' usb-0000:02:03.0-1, Huawei
CDC NCM device
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884677] NMI watchdog: BUG:
soft lockup - CPU#0 stuck for 24s! [usb-storage:7203]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884683] Modules linked in:
huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep
binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd
fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm
usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event
snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq
snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon
ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul
ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx
shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys
vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg
ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common
crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore
usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata
scsi_mod [last unloaded: huawei_cdc_ncm]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884740] CPU: 0 PID: 7203
Comm: usb-storage Tainted: G W 3.17.0-trunk-686-pae #1
Debian 3.17.4-1~exp1
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884742] Hardware name:
VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform,
BIOS 6.00 07/31/2013
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884744] task: dbfc4ab0 ti:
db27a000 task.ti: db27a000
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884778] EIP:
0060:[<c14a064f>] EFLAGS: 00000286 CPU: 0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884783] EIP is at
_raw_spin_unlock_irqrestore+0xf/0x20
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884785] EAX: 00000286 EBX:
00000000 ECX: 00000000 EDX: 00000286
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884786] ESI: 00000000 EDI:
db12c400 EBP: db27bb34 ESP: db27bb34
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884787] DS: 007b ES: 007b
FS: 00d8 GS: 00e0 SS: 0068
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884789] CR0: 80050033 CR2:
b77c5000 CR3: 1d4fb000 CR4: 001407f0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884837] Stack:
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884838] db27bbe0 e09f41e3
11c37a72 0000000d dbfc4af4 dbfc4af4 0000647d db27bb8c
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884841] e0806090 e0806054
db120001 00000006 dcf70ce0 00000004 e0806050 00000001
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884844] 00000286 db12c624
0000000d 00000001 dfff5648 d5472700 de400040 db27bbe0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884847] Call Trace:
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884858] [<e09f41e3>] ?
ehci_hub_control+0xf3/0xc80 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884893] [<c1167b9d>] ?
__kmalloc+0x37d/0x3f0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884896] [<c1081ec2>] ?
set_next_entity+0x52/0x70
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884898] [<c1087d0d>] ?
pick_next_task_fair+0x8ed/0xa30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884929] [<e08d9659>] ?
usb_hcd_submit_urb+0x339/0x9d0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884947] [<c100e6dc>] ?
__switch_to+0x11c/0x480
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884954] [<c10accd3>] ?
lock_timer_base.isra.39+0x23/0x50
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884960] [<e08db5ee>] ?
usb_start_wait_urb+0x4e/0x140 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884965] [<e08db787>] ?
usb_control_msg+0xa7/0xe0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884967] [<c149de4e>] ?
wait_for_completion_timeout+0x8e/0xe0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884972] [<e08cec40>] ?
set_port_feature+0x50/0x60 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884982] [<e08d067e>] ?
hub_port_reset+0x9e/0x600 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884984] [<c115f17a>] ?
dma_pool_free+0x2a/0x100
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884988] [<e09eb9f1>] ?
qh_destroy+0x61/0xa0 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884992] [<e08d0c56>] ?
hub_port_init+0x76/0xcb0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884996] [<e09f284d>] ?
ehci_endpoint_disable+0x2d/0x1c0 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884999] [<c107d5bb>] ?
try_to_wake_up+0x13b/0x2d0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885004] [<e08d19b9>] ?
usb_reset_and_verify_device+0x129/0x730 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885006] [<c1073792>] ?
__blocking_notifier_call_chain+0x42/0x60
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885007] [<c10737cf>] ?
blocking_notifier_call_chain+0x1f/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885009] [<c149e3f0>] ?
mutex_lock+0x10/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885014] [<e08d20ce>] ?
usb_reset_device+0x10e/0x280 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885019] [<e0ed7644>] ?
usb_stor_Bulk_transport+0x194/0x3e0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885021] [<e0ed7de0>] ?
usb_stor_port_reset+0x50/0x60 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885023] [<e0ed7e60>] ?
usb_stor_invoke_transport+0x70/0x4c0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885025] [<c107b07e>] ?
check_preempt_curr+0x6e/0x80
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885027] [<c107b0a8>] ?
ttwu_do_wakeup+0x18/0x140
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885029] [<c149e1c5>] ?
wait_for_completion_interruptible+0x95/0x180
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885031] [<c107d7b0>] ?
wake_up_state+0x10/0x10
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885034] [<e0ed93cf>] ?
usb_stor_control_thread+0x13f/0x230 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885037] [<c108cb6f>] ?
__wake_up_locked+0x1f/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885039] [<e0ed9290>] ?
usb_stor_disconnect+0xc0/0xc0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885041] [<c1072808>] ?
kthread+0xa8/0xc0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885044] [<c14a0e41>] ?
ret_from_kernel_thread+0x21/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885046] [<c1072760>] ?
kthread_create_on_node+0x110/0x110
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885047] Code: 5b 5e 5f 5d c3
80 43 04 01 fb 90 8d 74 26 00 eb e5 31 c0 eb e8 90 90 90 90 90 90 90
55 89 e5 3e 8d 74 26 00 80 00 01 89 d0 50 9d <8d> 74 26 00 5d c3 8d 74
26 00 8d bc 27 00 00 00 00 55 89 e5 3e
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.380743] usb 2-1: USB
disconnect, device number 4
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.380789] option 2-1:1.0: GSM
modem (1-port) converter detected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.381527] usb 2-1: GSM modem
(1-port) converter now attached to ttyUSB0
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.381547] option 2-1:1.1: GSM
modem (1-port) converter detected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382038] usb 2-1: GSM modem
(1-port) converter now attached to ttyUSB1
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382117] option1 ttyUSB0: GSM
modem (1-port) converter now disconnected from ttyUSB0
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382122] option 2-1:1.0:
device disconnected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382159] option1 ttyUSB1: GSM
modem (1-port) converter now disconnected from ttyUSB1
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382163] option 2-1:1.1:
device disconnected
Dec 15 13:19:17 vmw-wheezy kernel: [ 4763.866455] usbcore:
deregistering interface driver huawei_cdc_ncm
Dec 15 13:19:21 vmw-wheezy kernel: [ 4767.064010] usbcore: registered
new interface driver huawei_cdc_ncm

^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox