* [PATCH net-next 0/3] Code adjustment
From: Hayes Wang @ 2014-10-31 6:03 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Adjust some codes to make them more reasonable.
Hayes Wang (3):
r8152: remove the duplicate the init for the list of rx_done
r8152: clear the flag of SCHEDULE_TASKLET in tasklet
r8152: check RTL8152_UNPLUG and netif_running before autoresume
drivers/net/usb/r8152.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH net] r8152: stop submitting intr for -EPROTO
From: Hayes Wang @ 2014-10-31 5:35 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
For Renesas USB 3.0 host controller, when unplugging the usb hub which
has the RTL8153 plugged, the driver would get -EPROTO for interrupt
transfer. There is high probability to get the information of "HC died;
cleaning up", if the driver continues to submit the interrupt transfer
before the disconnect() is called.
[ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.383097] usb 9-1: USB disconnect, device number 2
[ 1024.383103] usb 9-1.4: USB disconnect, device number 6
[ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to stop endpoint command.
[ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting host.
[ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
[ 1029.421480] usb 8-1: USB disconnect, device number 2
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ca3c5d5..c6554c7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1162,6 +1162,9 @@ static void intr_callback(struct urb *urb)
case -ESHUTDOWN:
netif_device_detach(tp->netdev);
case -ENOENT:
+ case -EPROTO:
+ netif_info(tp, intr, tp->netdev,
+ "Stop submitting intr, status %d\n", status);
return;
case -EOVERFLOW:
netif_info(tp, intr, tp->netdev, "intr status -EOVERFLOW\n");
--
1.9.3
^ permalink raw reply related
* Re: net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Lothar Waßmann @ 2014-10-31 5:32 UTC (permalink / raw)
To: David Miller
Cc: netdev, rmk+kernel, Frank.Li, fabio.estevam, linux-kernel,
linux-arm-kernel
In-Reply-To: <20141030.121710.1524000348187962764.davem@davemloft.net>
Hi,
David Miller wrote:
> From: Lothar Waßmann <LW@KARO-electronics.de>
> Date: Thu, 30 Oct 2014 07:51:04 +0100
>
> >> Also, I don't thnk your DIV_ROUND_UP() eliminate for the loop
> >> in swap_buffer() is valid. The whole point is that the current
> >> code handles buffers which have a length which is not a multiple
> >> of 4 properly, after your change it will no longer do so.
> >>
> > Do you really think so?
>
> Yes, because you're rounding down so you'll miss the final
> partial word (if any).
>
Nope. DIV_ROUND_UP() would give '1' as upper bound for lengths from 1 to
4, '2' for lengths from 5 to 8 and so on.
The loop with increment 4 and i < len does exactly the same.
Try it for yourself, if you don't believe it.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH net-next] bridge: make proxy arp configurable
From: Stephen Hemminger @ 2014-10-31 3:09 UTC (permalink / raw)
To: Kyeyoon Park, David Miller; +Cc: netdev
This solves kernel build without INET enabled, and allows user
to control building this feature.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
net/bridge/Kconfig | 16 ++++++++++++++++
net/bridge/br_input.c | 4 ++++
net/bridge/br_sysfs_if.c | 4 ++++
3 files changed, 24 insertions(+)
--- a/net/bridge/Kconfig 2014-10-30 18:51:19.242364880 -0700
+++ b/net/bridge/Kconfig 2014-10-30 18:51:21.326379955 -0700
@@ -60,3 +60,19 @@ config BRIDGE_VLAN_FILTERING
Say N to exclude this support and reduce the binary size.
If unsure, say Y.
+
+config BRIDGE_ARP_PROXY
+ bool "ARP proxying"
+ depends on BRIDGE
+ depends on INET
+ default y
+ ---help---
+ If you say Y here, then the Ethernet bridge to keep track of
+ the hardware address to IP address mapping.
+
+ It is most useful when used as a wireless AP.
+
+ Say N to exclude this support and reduce the binary size.
+
+ If unsure, say Y.
+
--- a/net/bridge/br_input.c 2014-10-30 18:51:19.242364880 -0700
+++ b/net/bridge/br_input.c 2014-10-30 19:00:11.050205767 -0700
@@ -59,6 +59,7 @@ static int br_pass_frame_up(struct sk_bu
netif_receive_skb);
}
+#ifdef CONFIG_BRIDGE_PROXY_ARP
static void br_do_proxy_arp(struct sk_buff *skb, struct net_bridge *br,
u16 vid)
{
@@ -112,6 +113,7 @@ static void br_do_proxy_arp(struct sk_bu
neigh_release(n);
}
}
+#endif
/* note: already called with rcu_read_lock */
int br_handle_frame_finish(struct sk_buff *skb)
@@ -154,9 +156,11 @@ int br_handle_frame_finish(struct sk_buf
dst = NULL;
if (is_broadcast_ether_addr(dest)) {
+#ifdef CONFIG_BRIDGE_PROXY_ARP
if (p->flags & BR_PROXYARP &&
skb->protocol == htons(ETH_P_ARP))
br_do_proxy_arp(skb, br, vid);
+#endif
skb2 = skb;
unicast = false;
--- a/net/bridge/br_sysfs_if.c 2014-10-27 20:24:06.376733888 -0700
+++ b/net/bridge/br_sysfs_if.c 2014-10-30 18:58:58.209680384 -0700
@@ -170,7 +170,9 @@ BRPORT_ATTR_FLAG(bpdu_guard, BR_BPDU_GUA
BRPORT_ATTR_FLAG(root_block, BR_ROOT_BLOCK);
BRPORT_ATTR_FLAG(learning, BR_LEARNING);
BRPORT_ATTR_FLAG(unicast_flood, BR_FLOOD);
+#ifdef CONFIG_BRIDGE_PROXY_ARP
BRPORT_ATTR_FLAG(proxyarp, BR_PROXYARP);
+#endif
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
static ssize_t show_multicast_router(struct net_bridge_port *p, char *buf)
@@ -214,7 +216,9 @@ static const struct brport_attribute *br
&brport_attr_multicast_router,
&brport_attr_multicast_fast_leave,
#endif
+#ifdef CONFIG_BRIDGE_PROXY_ARP
&brport_attr_proxyarp,
+#endif
NULL
};
^ permalink raw reply
* Re: [PATCH] net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM with lengh 0
From: Andrew Lunn @ 2014-10-31 3:56 UTC (permalink / raw)
To: Guenter Roeck; +Cc: netdev, David S. Miller, Andrew Lunn, linux-kernel
In-Reply-To: <1414727415-5470-1-git-send-email-linux@roeck-us.net>
On Thu, Oct 30, 2014 at 08:50:15PM -0700, Guenter Roeck wrote:
> If a driver supports reading EEPROM but no EEPROM is installed in the system,
> the driver's get_eeprom_len function returns 0. ethtool will subsequently
> try to read that zero-length EEPROM anyway. If the driver does not support
> EEPROM access at all, this operation will return -EOPNOTSUPP. If the driver
> does support EEPROM access but no EEPROM is installed, the operation will
> return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
root@dir665:~# ethtool -e lan4
Cannot get EEPROM data: Operation not supported
Tested-by: Andrew Lunn <andrew@lunn.ch>
Thanks
Andrew
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Yuchung Cheng @ 2014-10-31 3:51 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Neal Cardwell, netdev, Eric Dumazet
In-Reply-To: <54521FD6.70403@redhat.com>
On Thu, Oct 30, 2014 at 7:24 PM, Marcelo Ricardo Leitner
<mleitner@redhat.com> wrote:
> On 30-10-2014 00:03, Neal Cardwell wrote:
>>
>> On Mon, Oct 27, 2014 at 2:49 PM, Marcelo Ricardo Leitner
>> <mleitner@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> We have a report from a customer saying that on a very calm connection,
>>> like
>>> having only a single data packet within some minutes, if this packet gets
>>> to
>>> be re-transmitted, retrans_stamp is only cleared when the next acked
>>> packet
>>> is received. But this may make we abort the connection too soon if this
>>> next
>>> packet also gets lost, because the reference for the initial loss is
>>> still
>>> for a big while ago..
>>
>> ...
>>>
>>> @@ -2382,31 +2382,32 @@ static inline bool tcp_may_undo(const struct
>>> tcp_sock *tp)
>>> static bool tcp_try_undo_recovery(struct sock *sk)
>>
>> ...
>>>
>>> if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
>>> /* Hold old state until something *above* high_seq
>>> * is ACKed. For Reno it is MUST to prevent false
>>> * fast retransmits (RFC2582). SACK TCP is safe. */
Or we can just remove this strange state-holding logic?
I couldn't find such a "MUST" statement in RFC2582. RFC2582 section 3
step 5 suggests exiting the recovery procedure when an ACK acknowledges
the "recover" variable (== tp->high_seq - 1).
Since we've called tcp_reset_reno_sack() before tcp_try_undo_recovery(),
I couldn't see how false fast retransmits can be triggered without
this state-holding.
Any insights?
>>> tcp_moderate_cwnd(tp);
>>> + tp->retrans_stamp = 0;
>>> return true;
>>> }
>>> tcp_set_ca_state(sk, TCP_CA_Open);
>>> return false;
>>> }
>>>
>>> We would still hold state, at least part of it.. WDYT?
>>
>>
>> This approach sounds OK to me as long as we include a check of
>> tcp_any_retrans_done(), as we do in the similar code paths (for
>> motivation, see the comment above tcp_any_retrans_done()).
>
>
> Yes, okay. I thought that this would be taken care of already by then but
> reading the code again now after your comment, I can see what you're saying.
> Thanks.
>
>> So it sounds fine to me if you change that one new line to the following
>> 2:
>>
>> + if (!tcp_any_retrans_done(sk))
>> + tp->retrans_stamp = 0;
>
>
> Will do.
>
>> Nice catch!
>
>
> A good part of it (including the diagram) was done by customer. :)
> I'll post the patch as soon as we sync with them (credits).
>
> Marcelo
>
^ permalink raw reply
* Re: [PATCH net] drivers/net: macvtap and tun depend on INET
From: David Miller @ 2014-10-31 3:50 UTC (permalink / raw)
To: ben; +Cc: netdev, fengguang.wu
In-Reply-To: <1414725031.16849.78.camel@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Fri, 31 Oct 2014 03:10:31 +0000
> These drivers now call ipv6_proxy_select_ident(), which is defined
> only if CONFIG_INET is enabled. However, they have really depended
> on CONFIG_INET for as long as they have allowed sending GSO packets
> from userland.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
> Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
> Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
Applied and queued up for -stable, thanks Ben.
^ permalink raw reply
* [PATCH] net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM with lengh 0
From: Guenter Roeck @ 2014-10-31 3:50 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Andrew Lunn, linux-kernel, Guenter Roeck
If a driver supports reading EEPROM but no EEPROM is installed in the system,
the driver's get_eeprom_len function returns 0. ethtool will subsequently
try to read that zero-length EEPROM anyway. If the driver does not support
EEPROM access at all, this operation will return -EOPNOTSUPP. If the driver
does support EEPROM access but no EEPROM is installed, the operation will
return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
net/core/ethtool.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 1600aa2..06dfb29 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1036,7 +1036,8 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
{
const struct ethtool_ops *ops = dev->ethtool_ops;
- if (!ops->get_eeprom || !ops->get_eeprom_len)
+ if (!ops->get_eeprom || !ops->get_eeprom_len ||
+ !ops->get_eeprom_len(dev))
return -EOPNOTSUPP;
return ethtool_get_any_eeprom(dev, useraddr, ops->get_eeprom,
@@ -1052,7 +1053,8 @@ static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
u8 *data;
int ret = 0;
- if (!ops->set_eeprom || !ops->get_eeprom_len)
+ if (!ops->set_eeprom || !ops->get_eeprom_len ||
+ !ops->get_eeprom_len(dev))
return -EOPNOTSUPP;
if (copy_from_user(&eeprom, useraddr, sizeof(eeprom)))
--
1.9.1
^ permalink raw reply related
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: David Miller @ 2014-10-31 3:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: fw, netdev
In-Reply-To: <1414711801.499.0.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 30 Oct 2014 16:30:01 -0700
> On Fri, 2014-10-31 at 00:16 +0100, Florian Westphal wrote:
>
>> I see. So that makes ecn=1 default a pure fantasy.
>
> Well, I had this dream about 2 or 3 years ago, but I eventually came to
> this (sad) conclusion.
We really should have done this from the beginning, but I guess we
lacked the courage to do so.
Some security nuts will say that the ECN bits are some covert channel
of communication and block connections based upon that, instead of,
you know, just clearing the bits.
Ok ok, Florian please resubmit your original patches. We'll go with a
boolean per-route override. Thanks for taking the time to discuss
this with us.
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: David Miller @ 2014-10-31 3:43 UTC (permalink / raw)
To: linux; +Cc: andrew, netdev, f.fainelli, linux-kernel
In-Reply-To: <5452F99D.5080201@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Thu, 30 Oct 2014 19:53:17 -0700
> On 10/30/2014 07:40 PM, Andrew Lunn wrote:
>>> As suspected, ethtool will attempt to read a zero-length eeprom.
>>>
>>> The following patch should solve the problem. Not sure if it is worth
>>> it,
>>> though, since this will change behavior for existing drivers.
>>
>> Yes, it changes behaviour, but it does make it more consistent.
>>
>> Probably it should be up to core network people to decide if this is
>> the write fix or leave it as is.
>>
>
> s/write/right/.
>
> The patch shows up in the netdev patchwork. David marked it as RFC,
> so we'll see where it goes.
As per your patch, I think we should fix this to not return a zero
length eeprom when the driver doesn't support it.
If dsa behaves outside of the defined behavior of what ethtool
implementations in ethernet drivers do, then it's ok to change it
because it's a bonafide bug fix in my eyes.
So if you submit this formally, I would apply it.
Thanks.
^ permalink raw reply
* Re: [PATCH] virtio_net: fix use after free
From: Eric Dumazet @ 2014-10-31 3:36 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization, David S. Miller
In-Reply-To: <1413378878-28118-1-git-send-email-mst@redhat.com>
On Wed, 2014-10-15 at 16:23 +0300, Michael S. Tsirkin wrote:
> commit 0b725a2ca61bedc33a2a63d0451d528b268cf975
> net: Remove ndo_xmit_flush netdev operation, use signalling instead.
>
> added code that looks at skb->xmit_more after the skb has
> been put in TX VQ. Since some paths process the ring and free the skb
> immediately, this can cause use after free.
>
> Fix by storing xmit_more in a local variable.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> David, am I using the API correctly?
> Seems to work for me.
> You used __netif_subqueue_stopped but that seems to use
> a slightly more expensive test_bit internally.
> The reason I added a variable for the txq here is because it's handy for
> BQL patch later on.
>
>
> drivers/net/virtio_net.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 3d0ce44..13d0a8b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -920,6 +920,8 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> int qnum = skb_get_queue_mapping(skb);
> struct send_queue *sq = &vi->sq[qnum];
> int err;
> + struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
> + bool kick = !skb->xmit_more;
>
> /* Free up any pending old buffers before queueing new ones. */
> free_old_xmit_skbs(sq);
> @@ -956,7 +958,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> }
> }
>
> - if (__netif_subqueue_stopped(dev, qnum) || !skb->xmit_more)
> + if (kick || netif_xmit_stopped(txq))
> virtqueue_kick(sq->vq);
>
> return NETDEV_TX_OK;
I must say I am kind of confused by this patch.
Why the skb_orphan(skb) & nf_reset(skb) do not have the same issue ?
It looks like following patch is needed ?
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b41ed41..17cc42c6a559 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -927,6 +927,10 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Free up any pending old buffers before queueing new ones. */
free_old_xmit_skbs(sq);
+ /* Don't wait up for transmitted skbs to be freed. */
+ skb_orphan(skb);
+ nf_reset(skb);
+
/* Try to transmit */
err = xmit_skb(sq, skb);
@@ -941,10 +945,6 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
- /* Don't wait up for transmitted skbs to be freed. */
- skb_orphan(skb);
- nf_reset(skb);
-
/* Apparently nice girls don't return TX_BUSY; stop the queue
* before it gets out of hand. Naturally, this wastes entries. */
if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
^ permalink raw reply related
* Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
From: Eric Dumazet @ 2014-10-31 3:19 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli, Ido Shamay
In-Reply-To: <CAJ3xEMjw9rRLBTEXT3cw0+CPRyvJgNbKVHpnmsukas-r=QwmyA@mail.gmail.com>
On Fri, 2014-10-31 at 01:25 +0200, Or Gerlitz wrote:
> On Thu, Oct 30, 2014 at 9:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
> >> Remove the code which goes through napi_gro_frags() on the RX path,
> >> use only napi_gro_receive().
>
> > Hmpff... napi_gro_frags() should be faster.
> > Have you benchmarked this ?
>
>
> yep we did, napi_gro_frags() was somehow better for single stream. Do
> you think we need to do it the other way around, e.g converge to use
> napi_gro_frags()?
napi_gro_frags() is faster because the napi->skb is reused fast (not
going through kfree_skb()/alloc_skb() for every fragment)
^ permalink raw reply
* [PATCH net] drivers/net: macvtap and tun depend on INET
From: Ben Hutchings @ 2014-10-31 3:10 UTC (permalink / raw)
To: netdev; +Cc: fengguang.wu
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled. However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
---
drivers/net/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 4706386..f9009be 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -135,6 +135,7 @@ config MACVLAN
config MACVTAP
tristate "MAC-VLAN based tap driver"
depends on MACVLAN
+ depends on INET
help
This adds a specialized tap character device driver that is based
on the MAC-VLAN network interface, called macvtap. A macvtap device
@@ -200,6 +201,7 @@ config RIONET_RX_SIZE
config TUN
tristate "Universal TUN/TAP device driver support"
+ depends on INET
select CRC32
---help---
TUN/TAP provides packet reception and transmission for user space
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* Re: [PATCH] net: gianfar: fix dma check map error when DMA_API_DEBUG is enabled
From: Kevin Hao @ 2014-10-31 3:09 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David Miller
In-Reply-To: <54526711.1080505@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
On Thu, Oct 30, 2014 at 06:28:01PM +0200, Claudiu Manoil wrote:
> On 10/30/2014 12:25 PM, Kevin Hao wrote:
>
> [...]
>
> >@@ -2406,6 +2416,25 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > spin_unlock_irqrestore(&tx_queue->txlock, flags);
> >
> > return NETDEV_TX_OK;
> >+
> >+dma_map_err:
> >+ txbdp = next_txbd(txbdp_start, base, tx_queue->tx_ring_size);
> >+ if (do_tstamp)
> >+ txbdp = next_txbd(txbdp, base, tx_queue->tx_ring_size);
> >+ for (i = 0; i < nr_frags; i++) {
> >+ lstatus = txbdp->lstatus;
> >+ if (!(lstatus & BD_LFLAG(TXBD_READY)))
> >+ break;
> >+
> >+ txbdp->lstatus = lstatus & ~BD_LFLAG(TXBD_READY);
> >+ bufaddr = txbdp->bufPtr;
> >+ dma_unmap_page(priv->dev, bufaddr, txbdp->length,
> >+ DMA_TO_DEVICE);
> >+ txbdp = next_txbd(txbdp, base, tx_queue->tx_ring_size);
> >+ }
> >+ gfar_wmb();
>
> Why use the wmb() memory barrier here?
Just want make sure that the update to the txbdp->lstatus is performed before
any possible update to the BD fields later. Maybe this seems a bit redundant.
But this is not in hot path, so we may tolerate this overhead for more safety.
Thanks,
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] VNIC: Adding support for Cavium ThunderX network controller
From: Stephen Hemminger @ 2014-10-31 2:54 UTC (permalink / raw)
To: Robert Richter
Cc: David S. Miller, Sunil Goutham, Robert Richter, Stefan Assmann,
linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <20141030165434.GW20170@rric.localhost>
On Thu, 30 Oct 2014 17:54:34 +0100
Robert Richter <rric@kernel.org> wrote:
> +#ifdef VNIC_RSS_SUPPORT
> +static int rss_config = RSS_IP_HASH_ENA | RSS_TCP_HASH_ENA | RSS_UDP_HASH_ENA;
> +module_param(rss_config, int, S_IRUGO);
> +MODULE_PARM_DESC(rss_config,
> + "RSS hash config [bits 8:0] (Bit0:L2 extended, 1:IP, 2:TCP, 3:TCP SYN, 4:UDP, 5:L4 extended, 6:ROCE 7:L3 bi-directional, 8:L4 bi-directional)");
> +#endif
This should managed be via ethtool ETHTOOL_GRXFH rather than a module parameter.
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-31 2:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, David S. Miller, Florian Fainelli, linux-kernel
In-Reply-To: <20141031024044.GA4082@lunn.ch>
On 10/30/2014 07:40 PM, Andrew Lunn wrote:
>> As suspected, ethtool will attempt to read a zero-length eeprom.
>>
>> The following patch should solve the problem. Not sure if it is worth it,
>> though, since this will change behavior for existing drivers.
>
> Yes, it changes behaviour, but it does make it more consistent.
>
> Probably it should be up to core network people to decide if this is
> the write fix or leave it as is.
>
s/write/right/.
The patch shows up in the netdev patchwork. David marked it as RFC,
so we'll see where it goes.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] VNIC: Adding support for Cavium ThunderX network controller
From: Stephen Hemminger @ 2014-10-31 2:45 UTC (permalink / raw)
To: Robert Richter
Cc: David S. Miller, Sunil Goutham, Robert Richter, Stefan Assmann,
linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <20141030165434.GW20170@rric.localhost>
On Thu, 30 Oct 2014 17:54:34 +0100
Robert Richter <rric@kernel.org> wrote:
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 1fa99a301817..80bd3336691e 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2324,6 +2324,8 @@
> #define PCI_DEVICE_ID_ALTIMA_AC9100 0x03ea
> #define PCI_DEVICE_ID_ALTIMA_AC1003 0x03eb
>
> +#define PCI_VENDOR_ID_CAVIUM 0x177d
I don't think PCI folks want this updated with every id anymore.
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Andrew Lunn @ 2014-10-31 2:40 UTC (permalink / raw)
To: Guenter Roeck
Cc: Andrew Lunn, netdev, David S. Miller, Florian Fainelli,
linux-kernel
In-Reply-To: <20141031010039.GA29492@roeck-us.net>
> As suspected, ethtool will attempt to read a zero-length eeprom.
>
> The following patch should solve the problem. Not sure if it is worth it,
> though, since this will change behavior for existing drivers.
Yes, it changes behaviour, but it does make it more consistent.
Probably it should be up to core network people to decide if this is
the write fix or leave it as is.
Andrew
^ permalink raw reply
* [PATCH net 2/2] mpls: Allow mpls_gso to be built as module
From: Pravin B Shelar @ 2014-10-30 7:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Pravin B Shelar, Simon Horman
Kconfig already allows mpls to be built as module. Following patch
fixes Makefile to do same.
CC: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/mpls/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mpls/Makefile b/net/mpls/Makefile
index 0a3c171..6dec088 100644
--- a/net/mpls/Makefile
+++ b/net/mpls/Makefile
@@ -1,4 +1,4 @@
#
# Makefile for MPLS.
#
-obj-y += mpls_gso.o
+obj-$(CONFIG_NET_MPLS_GSO) += mpls_gso.o
--
1.7.1
^ permalink raw reply related
* [PATCH net 1/2] mpls: Fix mpls_gso handler.
From: Pravin B Shelar @ 2014-10-30 7:49 UTC (permalink / raw)
To: davem; +Cc: netdev, Pravin B Shelar, Simon Horman
mpls gso handler needs to pull skb after segmenting skb.
CC: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/mpls/mpls_gso.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
index f0f5309..e3545f2 100644
--- a/net/mpls/mpls_gso.c
+++ b/net/mpls/mpls_gso.c
@@ -59,8 +59,7 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
* above pulled. It will be re-pushed after returning
* skb_mac_gso_segment(), an indirect caller of this function.
*/
- __skb_push(skb, skb->data - skb_mac_header(skb));
-
+ __skb_pull(skb, skb->data - skb_mac_header(skb));
out:
return segs;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-31 1:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, David S. Miller, Florian Fainelli, linux-kernel
In-Reply-To: <20141030223951.GA19489@roeck-us.net>
On Thu, Oct 30, 2014 at 03:39:51PM -0700, Guenter Roeck wrote:
> On Thu, Oct 30, 2014 at 10:11:31PM +0100, Andrew Lunn wrote:
> > > +static int dsa_slave_get_eeprom_len(struct net_device *dev)
> > > +{
> > > + struct dsa_slave_priv *p = netdev_priv(dev);
> > > + struct dsa_switch *ds = p->parent;
> > > +
> > > + if (ds->pd->eeprom_len)
> > > + return ds->pd->eeprom_len;
> > > +
> > > + if (ds->drv->get_eeprom_len)
> > > + return ds->drv->get_eeprom_len(ds);
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > Hi Guenter
> >
> > I just started doing some testing with this patchset. A bit late since
> > David just accepted it, but...
> >
> > root@dir665:~# ethtool -e lan4
> > Cannot get EEPROM data: Invalid argument
> > root@dir665:~# ethtool -e eth0
> > Cannot get EEPROM data: Operation not supported
> >
> > There is no eeprom for the hardware i'm testing. Operation not
> > supported seems like a better error code and Invalid argument, and is
> > what other network drivers i tried returned.
> >
> Hi Andrew,
>
> I think the problem is that the infrastructure code (net/core/ethtool.c)
> does not accept an error from the get_eeprom_len function, but instead
> assumes that reporting eeprom data is supported if a driver provides
> the access functions. The get_eeprom_len function returns 0 in your case,
> which in ethtool_get_any_eeprom() translates to -EINVAL because user space
> either requests no data or more data than available. I wonder why user
> space requests anything in the first place; I would have assumed that it
> reads the driver information first and is told that the eeprom length is 0,
> but I guess that is a different question.
>
> I quickly browsed through a couple of other drivers supporting get_eprom_len,
> and they all return 0 if there is no eeprom. Doesn't that mean that they all
> end up reporting -EINVAL if an attempt is made to read the eeprom ?
>
> The only solution that comes to my mind would be to have the infrastructure
> code check the return value from get_eeprom_len and return -EOPNOTSUPP
> if the reported eeprom length is 0. That would be an infrastructure change,
> though. Does that sound reasonable, or do you have a better idea ?
>
> In parallel, I'll have a look into the ethtool command to see why it
> requests eeprom data even though the reported eeprom length is 0.
>
As suspected, ethtool will attempt to read a zero-length eeprom.
The following patch should solve the problem. Not sure if it is worth it,
though, since this will change behavior for existing drivers.
Thanks,
Guenter
---
From: Guenter Roeck <linux@roeck-us.net>
Date: Thu, 30 Oct 2014 17:51:34 -0700
Subject: [RFC PATCH] net: ethtool: Return -EOPNOTSUPP if user space tries to read
EEPROM with lengh 0
If a driver supports reading EEPROM but no EEPROM is installed in the system,
the driver's get_eeprom_len function will return 0. ethtool will subsequently
try to read that zero-length EEPROM anyway. If the driver does not support
EEPROM access at all, this operation will return -EOPNOTSUPP. If the driver
does support EEPROM access but no EEPROM is installed, the operation will
return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
net/core/ethtool.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 1600aa2..06dfb29 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1036,7 +1036,8 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
{
const struct ethtool_ops *ops = dev->ethtool_ops;
- if (!ops->get_eeprom || !ops->get_eeprom_len)
+ if (!ops->get_eeprom || !ops->get_eeprom_len ||
+ !ops->get_eeprom_len(dev))
return -EOPNOTSUPP;
return ethtool_get_any_eeprom(dev, useraddr, ops->get_eeprom,
@@ -1052,7 +1053,8 @@ static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
u8 *data;
int ret = 0;
- if (!ops->set_eeprom || !ops->get_eeprom_len)
+ if (!ops->set_eeprom || !ops->get_eeprom_len ||
+ !ops->get_eeprom_len(dev))
return -EOPNOTSUPP;
if (copy_from_user(&eeprom, useraddr, sizeof(eeprom)))
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 8/8] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE
From: Yann Ylavic @ 2014-10-31 0:38 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev, Matan Barak, Amir Vadai, Saeed Mahameed,
Shani Michaeli, Jerry Chu
In-Reply-To: <1414685216-28907-9-git-send-email-ogerlitz@mellanox.com>
Hi,
On Thu, Oct 30, 2014 at 5:06 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
[...]
> +static int check_csum(struct mlx4_cqe *cqe, struct sk_buff *skb, int hwtstamp_rx_filter)
> +{
> + __wsum hw_checksum = 0;
> +
> + void *hdr = (u8 *)skb->data + sizeof(struct ethhdr);
> +
> + hw_checksum = csum_unfold((__force __sum16)cqe->checksum);
> +
> + if (((struct ethhdr *)skb->data)->h_proto == htons(ETH_P_8021Q) &&
> + hwtstamp_rx_filter != HWTSTAMP_FILTER_NONE) {
> + /* next protocol non IPv4 or IPv6 */
> + if (((struct vlan_hdr *)hdr)->h_vlan_encapsulated_proto
> + != htons(ETH_P_IP) ||
Shouldn't this be a AND (&&)?
> + ((struct vlan_hdr *)hdr)->h_vlan_encapsulated_proto
> + != htons(ETH_P_IPV6))
> + return -1;
Regards,
Yann.
^ permalink raw reply
* Re: Sporadic ESP payload corruption when using IPSec in NAT-T Transport Mode
From: Evan Gilman @ 2014-10-31 0:05 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, linux-kernel, netdev
In-Reply-To: <20140630132119.GA19500@gondor.apana.org.au>
Indeed, I am using aesni-intel. I have again been bitten by this
problem, but do not have the cycles to pinpoint the kernel version in
which the trouble was introduced. I have done a bit more research, and
have found that hosts running under Xen 4.4.2 are not affected
(regardless of kernel version), while hosts under Xen 4.1.6 and Xen
3.4.3 are affected. The latter is the version we are observing in AWS,
and ami-6d6b6028 (official Ubuntu Trusty image) is affected
out-of-the-box, with the latest kernel available for Trusty (linux
3.13.0). I can also confirm that the corruption ceases to occur after
unloading the aesni-intel kernel module.
I have been using the following test to identify hosts which are
affected, where hostA is known to be unaffected:
-- evan@hostA:~ $ dd if=/dev/zero | nc hostB 8080
2530292+0 records in
2530291+0 records out
1295508992 bytes (1.3 GB) copied, 413.288 s, 3.1 MB/s
^C-- evan@hostA:~ $
...
-- evan@hostB:~ $ nc -l 8080 | xxd -a
0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
189edea0:0000 1e30 e75c a3ef ab8b 8723 781c a4eb ...0.\.....#x...
189edeb0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0.\.....#x...
189edec0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0.\.....#x...
189eded0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0.\.....#x...
189edee0:6527 9d05 f655 6228 1366 5365 a932 2841 e'...Ub(.fSe.2(A
189edef0:2663 0000 0000 0000 0000 0000 0000 0000 &c..............
189edf00:0000 0000 0000 0000 0000 0000 0000 0000 ................
*
4927d4e0:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+
4927d4f0:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+
4927d500:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+
4927d510:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+
4927d520:01db 332d cf4b 3804 6f9c a5ad b9c8 0932 ..3-.K8.o......2
4927d530:0000 0000 0000 0000 0000 0000 0000 0000 ................
*
4bb51110:0000 54f8 a1cb 8f0d e916 80a2 0768 3bd3 ..T..........h;.
4bb51120:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;.
4bb51130:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;.
4bb51140:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;.
4bb51150:3794 20a0 1e44 ae70 25b7 7768 7d1d 38b1 7. ..D.p%.wh}.8.
4bb51160:8191 0000 0000 0000 0000 0000 0000 0000 ................
4bb51170:0000 0000 0000 0000 0000 0000 0000 0000 ................
*
4de3d390:0000 0000 0000 ......
-- evan@hostB:~ $
I hope that this simple test will aide others in reproducing the issue
and/or identifying if they are also affected.
It is possible that the issue has gone unnoticed by many as lots of
applications will gracefully handle the case. We just happened to hit
a bug in our application which failed to check the bound of a
particular value in it's protocol, causing the thread to OOM when it
tried to allocate memory for the bogus value.
Since the corruption can be cured by changing either Xen version or
Linux kernel version, could this be a bug in the interaction between
aesni-intel and Xen itself? If so, it might stand that a fix could be
shipped with a future kernel update, which would be great for people
like us whom cannot control nor convince our providers to upgrade Xen
(i.e. AWS).
I tried to find a reference to the previous report of aesni-intel
causing IPSec corruption under Xen - I'd be interested to read it if
anyone here has it on hand. For now, we are looking to blacklist
aesni-intel as we have no other suitable solution, and when combined
with our other bug, has a detrimental effect on our infrastructure.
On Mon, Jun 30, 2014 at 6:21 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jun 30, 2014 at 01:33:24PM +0200, Steffen Klassert wrote:
>> Ccing netdev.
>>
>> On Thu, Jun 26, 2014 at 02:12:30PM -0700, Evan Gilman wrote:
>> > Hi all
>> > We have a couple Ubuntu 10.04 hosts with kernel version 3.14.5 which are
>> > experiencing TCP payload corruption when using IPSec in NAT-T transport
>> > mode. All are running under Xen at third party providers. When
>> > communicating with other hosts using IPSec, we see that these corrupt TCP
>> > PDUs are still being received by the remote listener, even though the TCP
>> > checksum is invalid.
>> > All other checksums (IPSec authentication header and IP checksum) are
>> > good. So, we are thinking that corruption is happening during the ESP
>> > encapsulation and decapsulation phase (IPSec required for reproduction).
>> > The corruption occurs sporadically, and we have not found any one
>> > payload/packet combination that will reliably trigger it, though we can
>> > typically reproduce it in less than 30 minutes. We can do it very simply
>> > by reading from /dev/zero with dd and piping through netcat. It occurs
>> > whenever a 3.14.5 kernel is involved at either end of the conversation. I
>> > can send captures to those who are interested. Does any of this sound
>> > familiar?
>>
>> I can't remember anyone reporting such problems, but maybe someone
>> else does.
>
> I have seen one report where a Xen guest experienced IPsec corruption
> when using aesni-intel. However, in that case the corruption was at
> the authentication level. Are you using aesni-intel by any chance?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
evan
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add IPv6 into the hash computation for vRSS
From: David Miller @ 2014-10-31 0:02 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1414703237-11510-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 30 Oct 2014 14:07:17 -0700
> This will allow the workload spreading via vRSS for IPv6.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net 0/2] drivers/net,ipv6: Fix IPv6 fragment ID selection for virtio
From: David Miller @ 2014-10-31 0:02 UTC (permalink / raw)
To: ben; +Cc: netdev, hannes, virtualization
In-Reply-To: <1414693592.16849.61.camel@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Thu, 30 Oct 2014 18:26:32 +0000
> The virtio net protocol supports UFO but does not provide for passing a
> fragment ID for fragmentation of IPv6 packets. We used to generate a
> fragment ID wherever such a packet was fragmented, but currently we
> always use ID=0!
>
> v2: Add blank lines after declarations
Series applied and queued up for -stable, thanks Ben.
^ 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