* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: David Miller @ 2014-10-20 4:23 UTC (permalink / raw)
To: ben; +Cc: mleitner, stable, netdev, hannes
In-Reply-To: <1413774581.31953.12.camel@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 20 Oct 2014 04:09:41 +0100
> I've appplied this and the previous two patches mentioned ('ipv4: move
> route garbage collector to work queue' and 'ipv4: avoid parallel route
> cache gc executions'). But I didn't get the other two from you. The
> last batch of networking fixes I received and applied was dated
> 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
> nothing for 3.2 or 3.4. Did I miss one between these?
I'm at the point where I'm personally not going to go back more than
four releases, anything more than that is rediculous.
And this time that was 3.17, 3.16, 3.14, and 3.10
^ permalink raw reply
* Re: [PATCH 3.4-stable v2] ipv6: reallocate addrconf router for ipv6 address when lo device up
From: Ben Hutchings @ 2014-10-20 3:14 UTC (permalink / raw)
To: chenweilong
Cc: David Miller, netdev, Greg Kroah-Hartman, stable, Sabrina Dubroca,
Hannes Frederic Sowa, Gao feng, Li Zefan
In-Reply-To: <53E1E4C9.4010006@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Wed, 2014-08-06 at 16:18 +0800, chenweilong wrote:
> It fix the bug 67951 on bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=67951
>
> The patch can't be applied directly, as it' used the function introduced
> by "commit 94e187c0" ip6_rt_put(), that patch can't be applied directly
> either.
>
> ====================
>
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.
>
> This commit don't have a stable tag, but it fix the bug
> no reply after loopback down-up.It's very worthy to be
> applied to stable 3.4 kernels.
>
> The bug is 67951 on bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=67951
[...]
It looks like this is needed for 3.2.y as well, so I've queued it up.
Thanks.
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Ben Hutchings @ 2014-10-20 3:09 UTC (permalink / raw)
To: David Miller; +Cc: mleitner, stable, netdev, hannes
In-Reply-To: <20141013.135127.1915115817707962111.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Date: Mon, 13 Oct 2014 14:03:30 -0300
>
> > Further tests revealed that after moving the garbage collector to a work
> > queue and protecting it with a spinlock may leave the system prone to
> > soft lockups if bottom half gets very busy.
> >
> > It was reproced with a set of firewall rules that REJECTed packets. If
> > the NIC bottom half handler ends up running on the same CPU that is
> > running the garbage collector on a very large cache, the garbage
> > collector will not be able to do its job due to the amount of work
> > needed for handling the REJECTs and also won't reschedule.
> >
> > The fix is to disable bottom half during the garbage collecting, as it
> > already was in the first place (most calls to it came from softirqs).
> >
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Acked-by: David S. Miller <davem@davemloft.net>
> > Cc: stable@vger.kernel.org
>
> -stable folks, please integrate this directly, thanks!
I've appplied this and the previous two patches mentioned ('ipv4: move
route garbage collector to work queue' and 'ipv4: avoid parallel route
cache gc executions'). But I didn't get the other two from you. The
last batch of networking fixes I received and applied was dated
2014-08-07, and the next one I've seen is dated 2014-10-11 and has
nothing for 3.2 or 3.4. Did I miss one between these?
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* RE: [PATCH net] r8152: use cancel_delayed_work for runtime suspend
From: Hayes Wang @ 2014-10-20 2:19 UTC (permalink / raw)
To: Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic_swsd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1413661699.19391.2.camel-AfvqVibwNMkMNNZnWhT/Jw@public.gmane.org>
Oliver Neukum [mailto:oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org]
> Sent: Sunday, October 19, 2014 3:48 AM
[...]
> The diagnosis is good, the fix is not good. It opens a race
> during which the queued work can touch a suspended device.
The delayed work would wake up the device by
calling usb_autopm_get_interface() before
accessing the device. Besides, there is a mutex
to avoid the race.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2014-10-20 1:03 UTC (permalink / raw)
To: torvalds; +Cc: pablo, akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFz4UdVbZKPKwkesj0=1Yu7jLDP3Q3-jwe45b7gRU+0rog@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 19 Oct 2014 17:32:15 -0700
> Looks like the module license issue was just overlooked when moving
> the code out in commit c8d7b98bec43 ("netfilter: move nf_send_resetX()
> code to nf_reject_ipvX modules").
I think Pablo has a patch pending to address this, and indeed he does:
http://marc.info/?l=linux-netdev&m=141293491712312&w=2
Pablo please push this to me soon, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] net: make skb_gso_segment error handling more robust
From: David Miller @ 2014-10-20 0:39 UTC (permalink / raw)
To: fw; +Cc: netdev, edumazet
In-Reply-To: <1413751340-19621-3-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 19 Oct 2014 22:42:19 +0200
> skb_gso_segment has three possible return values:
> 1. a pointer to the first segmented skb
> 2. an errno value (IS_ERR())
> 3. NULL. This can happen when GSO is used for header verification.
>
> However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
> and would oops when NULL is returned.
>
> Note that these call sites should never actually see such a NULL return
> value; all callers mask out the GSO bits in the feature argument.
>
> However, in the past, there have been issues with some protocol handlers
> erronously not respecting the specified feature mask in some cases.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
I don't think it makes sense to return PTR_ERR(p) when
p is NULL.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2014-10-20 0:32 UTC (permalink / raw)
To: David Miller, Pablo Neira Ayuso
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20141019.132314.264021750039480460.davem@davemloft.net>
On Sun, Oct 19, 2014 at 10:23 AM, David Miller <davem@davemloft.net> wrote:
>
> A quick batch of bug fixes:
Ho humm.. Here's another networking issue with the current kernel:
nf_reject_ipv6: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
nf_reject_ipv6: Unknown symbol ip6_local_out (err 0)
Hmm? I'm not sure this is new, but I hadn't noticed it before. The
"unknown symbol" seems to be simply because ip6_local_out is GPL-only,
and without a proper license, 'nf_reject_ipv6' not only taints the
kernel but doesn't link properly..
Looks like the module license issue was just overlooked when moving
the code out in commit c8d7b98bec43 ("netfilter: move nf_send_resetX()
code to nf_reject_ipvX modules").
Linus
^ permalink raw reply
* Re: [PATCH 0/3] net: minor gso encapsulation fixes
From: Florian Westphal @ 2014-10-19 20:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> The following series fixes a minor bug in the gro segmentation handlers
> when handling encapsulation offloads.
In case you're wondering, 'is there a 4th patch in this series'?
There was, I intentionally did not send it (IMO its -next material)
but forgot to adjust the "PATCH x/y" part of the subject lines.
^ permalink raw reply
* [PATCH 3/4] net: core: handle encapsulation offloads when computing segment lengths
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
size of the inner network headers too.
This is 'mostly harmless'; tbf might send skb that is slightly over
quota or drop skb even if it would have fit.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/skbuff.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7b3df0d..eb4b48b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4059,15 +4059,22 @@ EXPORT_SYMBOL_GPL(skb_scrub_packet);
unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
{
const struct skb_shared_info *shinfo = skb_shinfo(skb);
+ unsigned int thlen = 0;
- if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
- return tcp_hdrlen(skb) + shinfo->gso_size;
+ if (skb->encapsulation) {
+ thlen = skb_inner_transport_header(skb) -
+ skb_transport_header(skb);
+ if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
+ thlen += inner_tcp_hdrlen(skb);
+ } else if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))) {
+ thlen = tcp_hdrlen(skb);
+ }
/* UFO sets gso_size to the size of the fragmentation
* payload, i.e. the size of the L4 (UDP) header is already
* accounted for.
*/
- return shinfo->gso_size;
+ return thlen + shinfo->gso_size;
}
EXPORT_SYMBOL_GPL(skb_gso_transport_seglen);
--
2.0.4
^ permalink raw reply related
* [PATCH 2/4] net: make skb_gso_segment error handling more robust
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
skb_gso_segment has three possible return values:
1. a pointer to the first segmented skb
2. an errno value (IS_ERR())
3. NULL. This can happen when GSO is used for header verification.
However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
and would oops when NULL is returned.
Note that these call sites should never actually see such a NULL return
value; all callers mask out the GSO bits in the feature argument.
However, in the past, there have been issues with some protocol handlers
erronously not respecting the specified feature mask in some cases.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv4/ip_output.c | 2 +-
net/netfilter/nfnetlink_queue_core.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/xfrm/xfrm_output.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e35b712..88a0ee3 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -231,7 +231,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)
*/
features = netif_skb_features(skb);
segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
- if (IS_ERR(segs)) {
+ if (IS_ERR_OR_NULL(segs)) {
kfree_skb(skb);
return -ENOMEM;
}
diff --git a/net/netfilter/nfnetlink_queue_core.c b/net/netfilter/nfnetlink_queue_core.c
index a82077d..7c60ccd 100644
--- a/net/netfilter/nfnetlink_queue_core.c
+++ b/net/netfilter/nfnetlink_queue_core.c
@@ -665,7 +665,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)
* returned by nf_queue. For instance, callers rely on -ECANCELED to
* mean 'ignore this hook'.
*/
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
goto out_err;
queued = 0;
err = 0;
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 2e31d9e..f98f708 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -322,7 +322,7 @@ static int queue_gso_packets(struct datapath *dp, struct sk_buff *skb,
int err;
segs = __skb_gso_segment(skb, NETIF_F_SG, false);
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
return PTR_ERR(segs);
/* Queue all of the segments. */
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 499d6c1..eef4334 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -155,7 +155,7 @@ static int xfrm_output_gso(struct sk_buff *skb)
segs = skb_gso_segment(skb, 0);
kfree_skb(skb);
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
return PTR_ERR(segs);
do {
--
2.0.4
^ permalink raw reply related
* [PATCH 1/4] net: gso: use feature flag argument in all protocol gso handlers
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal, Pravin B Shelar
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
skb_gso_segment() has a 'features' argument representing offload features
available to the output path.
A few handlers, e.g. GRE, instead re-fetch the features of skb->dev and use
those instead of the provided ones when handing encapsulation/tunnels.
Depending on dev->hw_enc_features of the output device skb_gso_segment() can
then return NULL even when the caller has disabled all GSO feature bits,
as segmentation of inner header thinks device will take care of segmentation.
This e.g. affects the tbf scheduler, which will silently drop GRE-encap GSO skbs
that did not fit the remaining token quota as the segmentation does not work
when device supports corresponding hw offload capabilities.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv4/af_inet.c | 2 +-
net/ipv4/gre_offload.c | 2 +-
net/ipv4/udp_offload.c | 2 +-
net/ipv6/ip6_offload.c | 2 +-
net/mpls/mpls_gso.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 92db7a6..8b7fe5b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1246,7 +1246,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
encap = SKB_GSO_CB(skb)->encap_level > 0;
if (encap)
- features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ features &= skb->dev->hw_enc_features;
SKB_GSO_CB(skb)->encap_level += ihl;
skb_reset_transport_header(skb);
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index a777295..e084534 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -68,7 +68,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
skb->mac_len = skb_inner_network_offset(skb);
/* segment inner packet. */
- enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ enc_features = skb->dev->hw_enc_features & features;
segs = skb_mac_gso_segment(skb, enc_features);
if (IS_ERR_OR_NULL(segs)) {
skb_gso_error_unwind(skb, protocol, ghl, mac_offset, mac_len);
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 507310e..6480cea 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -58,7 +58,7 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
skb->encap_hdr_csum = 1;
/* segment inner packet. */
- enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ enc_features = skb->dev->hw_enc_features & features;
segs = gso_inner_segment(skb, enc_features);
if (IS_ERR_OR_NULL(segs)) {
skb_gso_error_unwind(skb, protocol, tnl_hlen, mac_offset,
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 9034f76..820cdb1 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -89,7 +89,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
encap = SKB_GSO_CB(skb)->encap_level > 0;
if (encap)
- features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ features &= skb->dev->hw_enc_features;
SKB_GSO_CB(skb)->encap_level += sizeof(*ipv6h);
ipv6h = ipv6_hdr(skb);
diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
index e28ed2e..f0f5309 100644
--- a/net/mpls/mpls_gso.c
+++ b/net/mpls/mpls_gso.c
@@ -48,7 +48,7 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
__skb_push(skb, skb->mac_len);
/* Segment inner packet. */
- mpls_features = skb->dev->mpls_features & netif_skb_features(skb);
+ mpls_features = skb->dev->mpls_features & features;
segs = skb_mac_gso_segment(skb, mpls_features);
--
2.0.4
^ permalink raw reply related
* [PATCH 0/3] net: minor gso encapsulation fixes
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet
The following series fixes a minor bug in the gro segmentation handlers
when handling encapsulation offloads.
Theoretically this could cause kernel panic when the stack tries
to software-segment such a GRE offload packet, but it looks like there
is only one affected call site (tbf scheduler) and it handles NULL
return value.
I've included a followup patch to add IS_ERR_OR_NULL checks to all
the various skb_gso_segment call sites.
While looking into this, I also found that size computation of the individual
segments is incorrect as we do not consider skb->encapsulation.
core/skbuff.c | 13 ++++++++++---
ipv4/af_inet.c | 2 +-
ipv4/gre_offload.c | 2 +-
ipv4/ip_output.c | 2 +-
ipv4/udp_offload.c | 2 +-
ipv6/ip6_offload.c | 2 +-
mpls/mpls_gso.c | 2 +-
netfilter/nfnetlink_queue_core.c | 2 +-
openvswitch/datapath.c | 2 +-
xfrm/xfrm_output.c | 2 +-
10 files changed, 19 insertions(+), 12 deletions(-)
^ permalink raw reply
* qdisc running
From: Jamal Hadi Salim @ 2014-10-19 19:24 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: john Fastabend, Herbert Xu, netdev@vger.kernel.org, eric Dumazet
Jesper,
You asked at the meeting the point to qdisc running.
Original intent is to allow only one cpu to enter the lower half of the
qdisc path. IOW, if one cpu was already in the qdisc then that guy
could be used to dequeue packets. i.e this is good for batching.
Original idea was Herbert's with major improvement from Eric
and a small one from me.
For history of different tried approaches look at:
Look at slide 2:
http://vger.kernel.org/netconf2011_slides/jamal_netconf2011.pdf
then download the **amazing** flash animations which describe
that history.
http://vger.kernel.org/netconf2011_slides/netconf-2011-flash.tgz
Follow the bullets in slide2 and map to the flash animations.
If you go over them, you'll see it is still needed.
I think someone oughta put those **amazing** animations on some
website;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ipv6: tcp_v6_iff: fix compilation error on CONFIG_IPV6=n
From: Eric Dumazet @ 2014-10-19 18:50 UTC (permalink / raw)
To: Manfred Schlaegl; +Cc: David S. Miller, netdev, linux-kernel, Manfred Schlaegl
In-Reply-To: <5443FD47.7040003@gmx.at>
On Sun, 2014-10-19 at 20:04 +0200, Manfred Schlaegl wrote:
> If CONFIG_IPV6=n, then h6 in struct tcp_skb_cb.header is missing which
> leads to compilation-errors on tcp_v6_iff like:
>
> In file included from net/core/sock.c:140:0:
> include/net/tcp.h: In function ‘tcp_v6_iif’:
> include/net/tcp.h:738:32: error: ‘union <anonymous>’ has no member named
> ‘h6’
>
> This fix solves the problem by removing tcp_v6_iif, in case of
> CONFIG_IPV6=n.
>
> Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
> ---
Yes, this was fixed yesterday, thanks.
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=815afe1785da727ee48cd8e63ac4a3ec6c7459b3
^ permalink raw reply
* [PATCH] ipv6: tcp_v6_iff: fix compilation error on CONFIG_IPV6=n
From: Manfred Schlaegl @ 2014-10-19 18:04 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Manfred Schlaegl
If CONFIG_IPV6=n, then h6 in struct tcp_skb_cb.header is missing which
leads to compilation-errors on tcp_v6_iff like:
In file included from net/core/sock.c:140:0:
include/net/tcp.h: In function ‘tcp_v6_iif’:
include/net/tcp.h:738:32: error: ‘union <anonymous>’ has no member named
‘h6’
This fix solves the problem by removing tcp_v6_iif, in case of
CONFIG_IPV6=n.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
---
include/net/tcp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c9766f8..4062b4f 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -730,6 +730,7 @@ struct tcp_skb_cb {
#define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0]))
+#if IS_ENABLED(CONFIG_IPV6)
/* This is the variant of inet6_iif() that must be used by TCP,
* as TCP moves IP6CB into a different location in skb->cb[]
*/
@@ -737,6 +738,7 @@ static inline int tcp_v6_iif(const struct sk_buff *skb)
{
return TCP_SKB_CB(skb)->header.h6.iif;
}
+#endif
/* Due to TSO, an SKB can be composed of multiple actual
* packets. To keep these tracked properly, we use this.
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] net: s6gmac: remove driver
From: David Miller @ 2014-10-19 17:28 UTC (permalink / raw)
To: jcmvbkbc; +Cc: dg, netdev, linux-kernel
In-Reply-To: <CAMo8BfJ-wvDoDmm+HLHvC3VRUshdqU4eJchOGYt_YJsUktap8Q@mail.gmail.com>
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Sun, 19 Oct 2014 21:26:05 +0400
> On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
>> From: Daniel Glöckner <dg@emlix.com>
>> Date: Sun, 19 Oct 2014 00:49:05 +0200
>>
>>> The s6000 Xtensa support is removed from the kernel. There are no
>>> other chips using this driver.
>>
>> That's not what I see in Linus's current tree:
>
> David, s6000 removal is queued for 3.18.
Then there is zero reason for me to apply this to my networking
tree.
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: Max Filippov @ 2014-10-19 17:26 UTC (permalink / raw)
To: David Miller; +Cc: Daniel Glöckner, netdev, LKML
In-Reply-To: <20141019.124542.141206969262552652.davem@davemloft.net>
On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
> From: Daniel Glöckner <dg@emlix.com>
> Date: Sun, 19 Oct 2014 00:49:05 +0200
>
>> The s6000 Xtensa support is removed from the kernel. There are no
>> other chips using this driver.
>
> That's not what I see in Linus's current tree:
David, s6000 removal is queued for 3.18.
--
Thanks.
-- Max
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2014-10-19 17:23 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
A quick batch of bug fixes:
1) Fix build with IPV6 disabled, from Eric Dumazet.
2) Several more cases of caching SKB data pointers across
calls to pskb_may_pull(), thus referencing potentially
free'd memory. From Li RongQing.
3) DSA phy code tests operation presence improperly, instead
of going:
if (x->ops->foo)
r = x->ops->foo(args);
it was going:
if (x->ops->foo(args))
r = x->ops->foo(args);
Fix from Andew Lunn.
Please pull, thanks a lot.
The following changes since commit f2d9da1a8375cbe53df5b415d059429013a3a79f:
bna: fix skb->truesize underestimation (2014-10-17 23:56:33 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 228b16cb13dfa2f77354a9b144a07e86e2dda01c:
Net: DSA: Fix checking for get_phy_flags function (2014-10-19 12:46:31 -0400)
----------------------------------------------------------------
Andrew Lunn (1):
Net: DSA: Fix checking for get_phy_flags function
Eric Dumazet (1):
tcp: fix build error if IPv6 is not enabled
Li RongQing (3):
ipv4: fix a potential use after free in gre_offload.c
ipv6: fix a potential use after free in ip6_offload.c
ipv6: fix a potential use after free in sit.c
include/net/tcp.h | 2 ++
net/dsa/slave.c | 2 +-
net/ipv4/gre_offload.c | 6 +++---
net/ipv6/ip6_offload.c | 1 +
net/ipv6/sit.c | 6 +++---
5 files changed, 10 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: Fw: [Bug 86531] New: Kernel panic when using nmap
From: Alexei Starovoitov @ 2014-10-19 16:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20141019221149.2b590638@uryu.home.lan>
On Sun, Oct 19, 2014 at 6:41 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
>
> Begin forwarded message:
>
> Date: Sun, 19 Oct 2014 08:02:37 -0700
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 86531] New: Kernel panic when using nmap
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=86531
>
> Bug ID: 86531
> Summary: Kernel panic when using nmap
> Product: Networking
> Version: 2.5
> Kernel Version: 3.17.1
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: alxchk@gmail.com
> Regression: No
>
> Created attachment 154181
> --> https://bugzilla.kernel.org/attachment.cgi?id=154181&action=edit
> Crash log #1
>
> Strange crash appears the second time this day for me, when I starting nmap for
> scanning. Couldn't find any dependency. Anyway, dumps attached.
that's fixed in net tree and already in Linus's as well:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e0ee9c12157dc74e49e4731e0d07512e7d1ceb95
^ permalink raw reply
* Re: [PATCH v2] Net: DSA: Fix checking for get_phy_flags function
From: David Miller @ 2014-10-19 16:46 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <1413729707-1682-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 19 Oct 2014 16:41:47 +0200
> The check for the presence or not of the optional switch function
> get_phy_flags() called the function, rather than checked to see if it
> is a NULL pointer. This causes a derefernce of a NULL pointer on all
> switch chips except the sf2, the only switch to implement this call.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Fixes: 6819563e646a ("net: dsa: allow switch drivers to specify phy_device::dev_flags")
> Cc: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: David Miller @ 2014-10-19 16:45 UTC (permalink / raw)
To: dg; +Cc: netdev, linux-kernel
In-Reply-To: <1413672545-8535-1-git-send-email-dg@emlix.com>
From: Daniel Glöckner <dg@emlix.com>
Date: Sun, 19 Oct 2014 00:49:05 +0200
> The s6000 Xtensa support is removed from the kernel. There are no
> other chips using this driver.
That's not what I see in Linus's current tree:
[davem@localhost linux]$ git grep XTENSA_VARIANT_S6000
arch/xtensa/Kconfig:config XTENSA_VARIANT_S6000
arch/xtensa/Kconfig: default "s6000" if XTENSA_VARIANT_S6000
^ permalink raw reply
* Fw: [Bug 86531] New: Kernel panic when using nmap
From: Stephen Hemminger @ 2014-10-19 16:41 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 19 Oct 2014 08:02:37 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 86531] New: Kernel panic when using nmap
https://bugzilla.kernel.org/show_bug.cgi?id=86531
Bug ID: 86531
Summary: Kernel panic when using nmap
Product: Networking
Version: 2.5
Kernel Version: 3.17.1
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: alxchk@gmail.com
Regression: No
Created attachment 154181
--> https://bugzilla.kernel.org/attachment.cgi?id=154181&action=edit
Crash log #1
Strange crash appears the second time this day for me, when I starting nmap for
scanning. Couldn't find any dependency. Anyway, dumps attached.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH v2] Net: DSA: Fix checking for get_phy_flags function
From: Andrew Lunn @ 2014-10-19 14:41 UTC (permalink / raw)
To: davem; +Cc: f.fainelli, netdev, Andrew Lunn
The check for the presence or not of the optional switch function
get_phy_flags() called the function, rather than checked to see if it
is a NULL pointer. This causes a derefernce of a NULL pointer on all
switch chips except the sf2, the only switch to implement this call.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 6819563e646a ("net: dsa: allow switch drivers to specify phy_device::dev_flags")
Cc: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Don't truncate the Fixes subject.
net/dsa/slave.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 9d3b12b4e03c..fbcba4bc4e08 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -596,7 +596,7 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
netif_carrier_off(slave_dev);
if (p->phy != NULL) {
- if (ds->drv->get_phy_flags(ds, port))
+ if (ds->drv->get_phy_flags)
p->phy->dev_flags |= ds->drv->get_phy_flags(ds, port);
phy_attach(slave_dev, dev_name(&p->phy->dev),
--
2.1.1
^ permalink raw reply related
* [PATCH iproute2] ip link: Allow to filter devices by master dev
From: Vadim Kochan @ 2014-10-19 14:04 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Added 'master' option to 'ip link show' command
to filter devices by master dev.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipaddress.c | 16 ++++++++++++++++
ip/iplink.c | 2 +-
man/man8/ip-link.8.in | 9 ++++++++-
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 45729d8..8a0e2ab 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -56,6 +56,7 @@ static struct
int flushp;
int flushe;
int group;
+ int master;
} filter;
static int do_link;
@@ -480,6 +481,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
return -1;
}
+ if (tb[IFLA_MASTER]) {
+ int master = *(int*)RTA_DATA(tb[IFLA_MASTER]);
+ if (filter.master > 0 && master != filter.master)
+ return -1;
+ }
+ else if (filter.master > 0)
+ return -1;
+
if (n->nlmsg_type == RTM_DELLINK)
fprintf(fp, "Deleted ");
@@ -1215,6 +1224,13 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
NEXT_ARG();
if (rtnl_group_a2n(&filter.group, *argv))
invarg("Invalid \"group\" value\n", *argv);
+ } else if (strcmp(*argv, "master") == 0) {
+ int ifindex;
+ NEXT_ARG();
+ ifindex = ll_name_to_index(*argv);
+ if (!ifindex)
+ invarg("Device does not exist\n", *argv);
+ filter.master = ifindex;
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/iplink.c b/ip/iplink.c
index 43b26f4..ce6eb3e 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -82,7 +82,7 @@ void iplink_usage(void)
fprintf(stderr, " [ master DEVICE ]\n");
fprintf(stderr, " [ nomaster ]\n");
fprintf(stderr, " [ addrgenmode { eui64 | none } ]\n");
- fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up]\n");
+ fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up] [master DEV]\n");
if (iplink_have_newlink()) {
fprintf(stderr, " ip link help [ TYPE ]\n");
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 383917a..279fe39 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -144,7 +144,9 @@ ip-link \- network device configuration
.B ip link show
.RI "[ " DEVICE " | "
.B group
-.IR GROUP " ]"
+.IR GROUP " | "
+.B master
+.IR DEVICE " ]"
.SH "DESCRIPTION"
.SS ip link add - add virtual link
@@ -658,6 +660,11 @@ specifies what group of devices to show.
.B up
only display running interfaces.
+.TP
+.BI master " DEVICE "
+.I DEVICE
+specifies the master device which enslaves devices to show.
+
.SH "EXAMPLES"
.PP
ip link show
--
2.1.0
^ permalink raw reply related
* [PATCH net] ax88179_178a: fix bonding failure
From: Ian Morgan @ 2014-10-19 12:05 UTC (permalink / raw)
To: netdev
The following patch fixes a bug which causes the ax88179_178a driver to be
incapable of being added to a bond.
When I brought up the issue with the bonding maintainers, they indicated
that the real problem was with the NIC driver which must return zero for
success (of setting the MAC address). I see that several other NIC drivers
follow that pattern by either simply always returing zero, or by passing
through a negative (error) result while rewriting any positive return code
to zero. With that same philisophy applied to the ax88179_178a driver, it
allows it to work correctly with the bonding driver.
I believe this is suitable for queuing in -stable, as it's a small, simple,
and obvious fix that corrects a defect with no other known workaround.
This patch is against vanilla 3.17(.0).
Signed-off-by: Ian Morgan <imorgan@primordial.ca>
drivers/net/usb/ax88179_178a.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- linux-3.17/drivers/net/usb/ax88179_178a.c.orig 2014-10-05 15:23:04.000000000 -0400
+++ linux-3.17/drivers/net/usb/ax88179_178a.c 2014-10-15 09:07:31.217810217 -0400
@@ -937,6 +937,7 @@ static int ax88179_set_mac_addr(struct n
{
struct usbnet *dev = netdev_priv(net);
struct sockaddr *addr = p;
+ int ret;
if (netif_running(net))
return -EBUSY;
@@ -946,8 +947,12 @@ static int ax88179_set_mac_addr(struct n
memcpy(net->dev_addr, addr->sa_data, ETH_ALEN);
/* Set the MAC address */
- return ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN,
+ ret = ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN,
ETH_ALEN, net->dev_addr);
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static const struct net_device_ops ax88179_netdev_ops = {
--
Ian Morgan
^ 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