* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Eric Dumazet @ 2012-12-28 18:11 UTC (permalink / raw)
To: Andrew Savchenko; +Cc: netdev
In-Reply-To: <20121223150627.d7ebcf6a.bircoph@gmail.com>
On Sun, 2012-12-23 at 15:06 +0400, Andrew Savchenko wrote:
> Hello,
>
> the bug has struck again on 3.7.0, see details below.
>
> On Wed, 12 Dec 2012 12:27:16 +0400 Andrew Savchenko wrote:
> > [...]
> > > > Some driver or protocol stack is messing with skb->truesize, as
> > > > your /proc/net/udp file contains anomalies :
> > > >
> > > > $ cat /proc/net/udp
> > > > sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
> > > > ...
> > > > 323: 074A070A:007B 00000000:0000 07 FFFDF700:00000000 00:00000000 00000000 123 0 254469 2 ffff88003d581880 0
> > > > ...
> > > > 323: 00FCA8C0:007B 00000000:0000 07 FFFFF900:00000000 00:00000000 00000000 0 0 5187 2 ffff880039993880 0
> > > >
> > > > Its clearly not possible to get tx_queue = 0xFFFDF700 or 0xFFFFF900
> > > >
> > > > So what drivers handle following IP addresses : 192.168.252.0 , 10.7.74.7 ?
> > >
> > > 192.168.252.0 is handled by eth0 interface running on Realtek
> > > Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (10ec:8139) NIC.
> > > Kernel driver 8139too. This interface handles multiple subnetworks:
> > >
> > > # ip addr show eth0
> > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> > > link/ether 00:80:48:30:ca:f3 brd ff:ff:ff:ff:ff:ff
> > > inet 10.51.15.126/25 brd 10.51.15.127 scope global eth0
> > > inet 192.168.252.0/31 scope global eth0
> > >
> > > 10.7.74.7 is an l2tp connection handled by ppp over l2tp:
> > > CONFIG_PPPOL2TP=y
> > > It is running on top of eth0 described above.
> > >
> > > # ip addr show ppp0
> > > 65: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
> > > link/ppp
> > > inet 10.7.74.7 peer 10.7.2.18/32 scope global ppp0
> >
> > I updated kernel on this system to 3.7.0 and udp anomaly is still
> > present:
> >
> > $ cat /proc/net/udp
> > sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
> > 0: 00000000:06A5 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5326 2 ffff88003dbf0a80 0
> > 8: 00000000:7EAD 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5157 2 ffff8800398c2000 0
> > 89: 00000000:90FE 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5101 2 ffff88003dbd3500 0
> > 160: 0100007F:2745 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4598 2 ffff88003d612700 0
> > 184: 0100007F:035D 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4774 2 ffff88003d612a80 0
> > 217: 00000000:857E 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5195 2 ffff8800398c2700 0
> > 318: 00000000:A9E3 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4782 2 ffff88003d612e00 0
> > 335: 7E0F330A:01F4 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5303 2 ffff8800398c2e00 0
> > 348: 00000000:0801 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5186 2 ffff8800398c2380 0
> > 387: 7E0F330A:DE28 1400320A:06A5 01 00000000:00000000 00:00000000 00000000 0 0 5332 4 ffff88003dbf0e00 0
> > 400: 010013AC:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4842 2 ffff88003d613880 0
> > 400: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4841 2 ffff88003d613500 0
> > 414: 00000000:0043 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5273 2 ffff8800398c2a80 0
> > 458: 00000000:006F 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4483 2 ffff88003d612000 0
> > 459: 00000000:0270 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4507 2 ffff88003d612380 0
> > 466: 00000000:0277 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4802 2 ffff88003d613180 0
> > 470: 076A070A:007B 00000000:0000 07 FFFF4600:00000000 00:00000000 00000000 123 0 5552 2 ffff880039974380 0
> > 470: 010213AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4986 2 ffff88003dbd3180 0
> > 470: 010013AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4985 2 ffff88003dbd2e00 0
> > 470: 00FCA8C0:007B 00000000:0000 07 FFFFFB00:00000000 00:00000000 00000000 0 0 4984 2 ffff88003dbd2a80 0
> > 470: 7E0F330A:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4983 2 ffff88003dbd2700 0
> > 470: 0100007F:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4982 2 ffff88003dbd2380 0
> > 470: 00000000:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4975 2 ffff88003d613c00 0
> > 484: FF0013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5316 2 ffff88003dbf0000 0
> > 484: 010013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5315 2 ffff88003dbd3880 0
> > 484: FF0213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5312 2 ffff8800398c3c00 0
> > 484: 010213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5311 2 ffff8800398c3880 0
> > 484: 00000000:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5308 2 ffff8800398c3180 0
> > 485: FF0013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5318 2 ffff88003dbf0700 0
> > 485: 010013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5317 2 ffff88003dbf0380 0
> > 485: FF0213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5314 2 ffff88003dbd3c00 0
> > 485: 010213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5313 2 ffff88003dbd2000 0
> > 485: 00000000:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5309 2 ffff8800398c3500 0
> >
> > The bug hasn't shown up yet, I'll need to wait for about a week to see
> > if it is reproducible.
>
> I hit this bug again on uptime 11 days on 3.7.0 vanilla kernel.
> See kernel config, /prot/net/upd, netstat -s and dropwatch logs
> attached to this mail. This bug happens on UDP DNS requests only,
> TCP requests work fine, see dig.log attached.
>
> Increasing of net.ipv4.udp_mem from
> 24150 32201 48300
> to
> 100000 150000 200000
> helps, but I'm afraid only temporary again.
>
> Dropwatch data was collected in the following way:
> - dropwatch.bug.* files contain data obtained after bug occurred;
> - dropwatch.*.background files contain background data when no
> host or dig test was running; this system has active firewall
> and complicated routing, ipv6 disabled via sysctl, etc, so some
> drops are normal;
> - dropwatch.*.host.request shows dropped packets recorded during
> host ya.ru request; of course, during this time some background
> packets were recorded as well (dropwatch doesn't support filtering
> at this moment);
> - dropwatch.nobug.* data was collected after the bug was
> workarounded via net.ipv4.upd_mem as described above.
>
> As can be seen from dropwatch logs, drop in __udp_queue_rcv_skb+61
> happens only on host request on bug conditions, thus something is
> wrong there.
>
> Best regards,
> Andrew Savchenko
Thanks a lot !
I see strange drops in dev_hard_start_xmit()
l2tp needs some care.
Please try the following patch, as skb_cow_head() API
doesnt really ease skb->truesize exact tracking anyway, better not mess
with it.
net/l2tp/l2tp_core.c | 6 ------
net/l2tp/l2tp_ppp.c | 6 ------
2 files changed, 12 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 1a9f372..d77e655 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1123,8 +1123,6 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
struct udphdr *uh;
struct inet_sock *inet;
__wsum csum;
- int old_headroom;
- int new_headroom;
int headroom;
int uhlen = (tunnel->encap == L2TP_ENCAPTYPE_UDP) ? sizeof(struct udphdr) : 0;
int udp_len;
@@ -1136,16 +1134,12 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
*/
headroom = NET_SKB_PAD + sizeof(struct iphdr) +
uhlen + hdr_len;
- old_headroom = skb_headroom(skb);
if (skb_cow_head(skb, headroom)) {
kfree_skb(skb);
return NET_XMIT_DROP;
}
- new_headroom = skb_headroom(skb);
skb_orphan(skb);
- skb->truesize += new_headroom - old_headroom;
-
/* Setup L2TP header */
session->build_header(session, __skb_push(skb, hdr_len));
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 286366e..716605c 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -388,8 +388,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
struct l2tp_session *session;
struct l2tp_tunnel *tunnel;
struct pppol2tp_session *ps;
- int old_headroom;
- int new_headroom;
int uhlen, headroom;
if (sock_flag(sk, SOCK_DEAD) || !(sk->sk_state & PPPOX_CONNECTED))
@@ -408,7 +406,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
if (tunnel == NULL)
goto abort_put_sess;
- old_headroom = skb_headroom(skb);
uhlen = (tunnel->encap == L2TP_ENCAPTYPE_UDP) ? sizeof(struct udphdr) : 0;
headroom = NET_SKB_PAD +
sizeof(struct iphdr) + /* IP header */
@@ -418,9 +415,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
if (skb_cow_head(skb, headroom))
goto abort_put_sess_tun;
- new_headroom = skb_headroom(skb);
- skb->truesize += new_headroom - old_headroom;
-
/* Setup PPP header */
__skb_push(skb, sizeof(ppph));
skb->data[0] = ppph[0];
^ permalink raw reply related
* Re: Panic: dma_map_area overflow 66 bytes on 3.7+
From: Eric Dumazet @ 2012-12-28 19:53 UTC (permalink / raw)
To: Martin Nybo Andersen
Cc: David S. Miller, Michal Schmidt, linux-kernel, netdev
In-Reply-To: <201212282005.10812.tweek@tweek.dk>
On Fri, 2012-12-28 at 20:05 +0100, Martin Nybo Andersen wrote:
> Hi list,
>
> Since the release of 3.7 my main computer has been panicking a couple of
> times on both 3.7.0 and 3.7.1 because of a 'dma_map_area overflow xx bytes'.
>
> Example screen shot:
> http://www.tweek.dk/panic.jpg
>
> I can reproduce it somewhat easily by visiting http://www.openstreetmap.org/
> and zoom erratically with the scroll-button on the mouse.
>
> The panic seems to occur on line 229 of arch/x86/kernel/amd_gart_64.c, and
> reverting commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd (r8169: use
> unlimited DMA burst for TX) seems to fix the problem for me (at least I've
> not been able to make it panic as before (yet)).
>
>
> lspci -v:
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS480 Host Bridge (rev 01)
> 00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI-X Root Port
> 00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI Bridge
> 00:12.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA
> 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0)
> 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1)
> 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2)
> 00:13.3 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3)
> 00:13.4 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4)
> 00:13.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI)
> 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 13)
> 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB600 IDE
> 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)
> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge
> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> 02:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
> 03:07.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)
>
>
> Please tell, if more info is needed.
Seems you have CONFIG_IOMMU_DEBUG, is it really what you want ?
It seems a bit strange we panic in this case
( panic_on_overflow = 1;)
You could try to add iommu=nopanic to your boot command : packet should
be dropped, instead of panic.
config IOMMU_DEBUG
bool "Enable IOMMU debugging"
depends on GART_IOMMU && DEBUG_KERNEL
depends on X86_64
---help---
Force the IOMMU to on even when you have less than 4GB of
memory and add debugging code. On overflow always panic. And
allow to enable IOMMU leak tracing. Can be disabled at boot
time with iommu=noforce. This will also enable scatter gather
list merging. Currently not recommended for production
code. When you use it make sure you have a big enough
IOMMU/AGP aperture. Most of the options enabled by this can
be set more finegrained using the iommu= command line
options. See Documentation/x86/x86_64/boot-options.txt for more
details.
^ permalink raw reply
* [PATCH net-next] net: filter: return -EINVAL if BPF_S_ANC* operation is not supported
From: Daniel Borkmann @ 2012-12-28 20:50 UTC (permalink / raw)
To: davem; +Cc: ani, netdev, Daniel Borkmann, Eric Dumazet
Currently, we return -EINVAL for malformed or wrong BPF filters.
However, this is not done for BPF_S_ANC* operations, which makes it
more difficult to detect if it's actually supported or not by the
BPF machine. Therefore, we should also return -EINVAL if K is within
the SKF_AD_OFF universe and the ancillary operation did not match.
Why exactly is it needed? If tools such as libpcap/tcpdump want to
make use of new ancillary operations (like filtering VLAN in kernel
space), there is currently no sane way to test if this feature /
BPF_S_ANC* op is present or not, since no error is returned. This
patch will make life easier for that and allow for a proper usage
for user space applications.
There was concern, if this patch will break userland. Short answer: Yes
and no. Long answer: It will "break" only for code that calls ...
{ BPF_LD | BPF_(W|H|B) | BPF_ABS, 0, 0, <K> },
... where <K> is in [0xfffff000, 0xffffffff] _and_ <K> is *not* an
ancillary. And here comes the BUT: assuming some *old* code will have
such an instruction where <K> is between [0xfffff000, 0xffffffff] and
it doesn't know ancillary operations, then this will give a
non-expected / unwanted behavior as well (since we do not return the
BPF machine with 0 after a failed load_pointer(), which was the case
before introducing ancillary operations, but load sth. into the
accumulator instead, and continue with the next instruction, for
instance). Thus, user space code would already have been broken by
introducing ancillary operations into the BPF machine per se. Code
that does such a direct load, e.g. "load word at packet offset
0xffffffff into accumulator" ("ld [0xffffffff]") is quite broken,
isn't it? The whole assumption of ancillary operations is that no-one
intentionally calls things like "ld [0xffffffff]" and expect this
word to be loaded from such a packet offset. Hence, we can also safely
make use of this feature testing patch and facilitate application
development. Therefore, at least from this patch onwards, we have
*for sure* a check whether current or in future implemented BPF_S_ANC*
ops are supported in the kernel. Patch was tested on x86_64.
(Thanks to Eric for the previous review.)
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Ani Sinha <ani@aristanetworks.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/core/filter.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index c23543c..2ead2a9 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -532,6 +532,7 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
[BPF_JMP|BPF_JSET|BPF_X] = BPF_S_JMP_JSET_X,
};
int pc;
+ bool anc_found;
if (flen == 0 || flen > BPF_MAXINSNS)
return -EINVAL;
@@ -592,8 +593,10 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
case BPF_S_LD_W_ABS:
case BPF_S_LD_H_ABS:
case BPF_S_LD_B_ABS:
+ anc_found = false;
#define ANCILLARY(CODE) case SKF_AD_OFF + SKF_AD_##CODE: \
code = BPF_S_ANC_##CODE; \
+ anc_found = true; \
break
switch (ftest->k) {
ANCILLARY(PROTOCOL);
@@ -610,6 +613,10 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
ANCILLARY(VLAN_TAG);
ANCILLARY(VLAN_TAG_PRESENT);
}
+
+ /* ancillary operation unknown or unsupported */
+ if (anc_found == false && ftest->k >= SKF_AD_OFF)
+ return -EINVAL;
}
ftest->code = code;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 03/25] sja1000: don't use [delayed_]work_pending()
From: Tejun Heo @ 2012-12-28 21:40 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, wg, netdev
In-Reply-To: <20121222.000111.1132195626602429566.davem@davemloft.net>
On Sat, Dec 22, 2012 at 12:01:11AM -0800, David Miller wrote:
> From: Tejun Heo <tj@kernel.org>
> Date: Fri, 21 Dec 2012 17:56:53 -0800
>
> > There's no need to test whether a (delayed) work item in pending
> > before queueing, flushing or cancelling it. Most uses are unnecessary
> > and quite a few of them are buggy.
> >
> > Remove unnecessary pending tests from sja1000. Only compile tested.
> >
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Cc: Wolfgang Grandegger <wg@grandegger.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > ---
> > Please let me know how this patch should be routed. I can take it
> > through the workqueue tree if necessary.
>
> I would suggest just taking it via the workqueue tree, thanks Tejun.
Applied to wq/for-3.9-cleanups w/ your Acked-by added.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 00/12] netfilter fixes for 3.8-rc1
From: David Miller @ 2012-12-28 22:31 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Fri, 28 Dec 2012 12:52:39 +0100
> git://1984.lsi.us.es/nf master
Pulled, thanks Pablo.
> Have a nice entrance for the new year. Thanks.
Thanks, you too.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: Herbert Xu @ 2012-12-28 22:42 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-crypto, Steffen Klassert, netdev, David S. Miller
In-Reply-To: <20121228100448.11073.25546.stgit@localhost6.localdomain6>
On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> I'm not sure how this patchset should be dealt with (should 1st patch go
> through different tree than 2nd and 3rd?), so therefore it's RFC.
>
> Second patch makes rfc3686 template work with asynchronous block ciphers and
> third patch changes aesni-intel to use this template. First patch fixed problem
> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
> 2nd patch breaks aes-ctr with IPSEC.
I think the easiest way is to have these patches go through Dave's
tree.
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
^ permalink raw reply
* Re: [patch net-next V3,repost 0/4] net: allow to change carrier from userspace
From: David Miller @ 2012-12-28 23:21 UTC (permalink / raw)
To: jiri
Cc: netdev, edumazet, bhutchings, mirqus, shemminger, greearb, fbl,
john.r.fastabend
In-Reply-To: <1356688180-3549-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 28 Dec 2012 10:49:36 +0100
> This is basically a V3 of a repost of my previous patchset:
> "[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
>
> The way net-sysfs stores values changed and this patchset reflects it.
> Also, I exposed carrier via rtnetlink iface.
>
> So far, only dummy driver uses carrier change ndo. In very near future
> team driver will use that as well.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: removes a superfluous check and add a statistic
From: David Miller @ 2012-12-28 23:22 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, steffen.klassert
In-Reply-To: <1356681988-7985-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 28 Dec 2012 16:06:28 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> Remove the check if x->km.state equal to XFRM_STATE_VALID in
> xfrm_state_check_expire(), which will be done before call
> xfrm_state_check_expire().
>
> add a LINUX_MIB_XFRMOUTSTATEINVALID statistic to record the
> outbound error due to invalid xfrm state.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
I'll let Steffen pick this up when he returns from his holiday
break.
Please CC: him on all IPSEC changes since he is the primary
IPSEC maintainer and is the one who will integrate your IPSEC
patches into his ipsec GIT tree.
^ permalink raw reply
* Re: [RFC PATCH] ah4/esp4: set transport header correctly for IPsec tunnel mode.
From: David Miller @ 2012-12-28 23:22 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, steffen.klassert
In-Reply-To: <1356682036-25642-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 28 Dec 2012 16:07:16 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> IPsec tunnel does not set ECN field to CE in inner header when
> the ECN field in the outer header is CE, and the ECN field in
> the inner header is ECT(0) or ECT(1).
>
> The cause is ipip_hdr() does not return the correct address of
> inner header since skb->transport-header is not the inner header
> after esp_input_done2(), or ah_input().
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Likewise I'll leave this to Steffen.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: David Miller @ 2012-12-28 23:23 UTC (permalink / raw)
To: herbert; +Cc: jussi.kivilinna, linux-crypto, steffen.klassert, netdev
In-Reply-To: <20121228224248.GA29448@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 29 Dec 2012 09:42:49 +1100
> On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
>> I'm not sure how this patchset should be dealt with (should 1st patch go
>> through different tree than 2nd and 3rd?), so therefore it's RFC.
>>
>> Second patch makes rfc3686 template work with asynchronous block ciphers and
>> third patch changes aesni-intel to use this template. First patch fixed problem
>> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
>> 2nd patch breaks aes-ctr with IPSEC.
>
> I think the easiest way is to have these patches go through Dave's
> tree.
Better yet, Steffen's IPSEC tree :-)
^ permalink raw reply
* Re: [PATCH net-next] bridge: respect RFC2863 operational state
From: David Miller @ 2012-12-28 23:27 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20121227222854.6ec132dd@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 27 Dec 2012 22:28:54 -0800
> spin_lock_bh(&br->lock);
> - if (netif_running(dev) && netif_carrier_ok(dev)) {
> + if (netif_running(dev) && netif_oper_up(dev))
> if (p->state == BR_STATE_DISABLED)
> br_stp_enable_port(p);
> } else {
You didn't even try to compile this.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: add Telekom Speedstick LTE II
From: David Miller @ 2012-12-28 23:28 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1356712255-9488-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Fri, 28 Dec 2012 17:30:55 +0100
> also known as Alcatel One Touch L100V LTE
>
> The driver description files gives these names to the vendor specific
> functions on this modem:
>
> Application1: VID_1BBB&PID_011E&MI_00
> Application2: VID_1BBB&PID_011E&MI_01
> Modem: VID_1BBB&PID_011E&MI_03
> Ethernet: VID_1BBB&PID_011E&MI_04
>
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: use per task frag allocator in skb_append_datato_frags
From: David Miller @ 2012-12-28 23:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1356710797.21409.150.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 28 Dec 2012 08:06:37 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Use the new per task frag allocator in skb_append_datato_frags(),
> to reduce number of frags and page allocator overhead.
>
> Tested:
> ifconfig lo mtu 16436
> perf record netperf -t UDP_STREAM ; perf report
>
> before :
> Throughput: 32928 Mbit/s
...
> after:
> Throughput: 47185 Mbit/s
...
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Very nice, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH V2] forcedeth: Fix WARNINGS that result when DMA mapping is not checked
From: David Miller @ 2012-12-28 23:30 UTC (permalink / raw)
To: Larry.Finger; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1356665141-4498-1-git-send-email-Larry.Finger@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Thu, 27 Dec 2012 21:25:41 -0600
> With 3.8-rc1, the first call of pci_map_single() that is not checked
> with a corresponding pci_dma_mapping_error() call results in a warning
> with a splat as follows:
>
> WARNING: at lib/dma-debug.c:933 check_unmap+0x480/0x950()
> Hardware name: HP Pavilion dv2700 Notebook PC
> forcedeth 0000:00:0a.0: DMA-API: device driver failed to check
> map error[device address=0x00000000b176e002] [size=90 bytes] [mapped as single]
>
> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Applied, thanks Larry.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: Herbert Xu @ 2012-12-29 0:08 UTC (permalink / raw)
To: David Miller; +Cc: jussi.kivilinna, linux-crypto, steffen.klassert, netdev
In-Reply-To: <20121228.152311.290755667605168896.davem@davemloft.net>
On Fri, Dec 28, 2012 at 03:23:11PM -0800, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 29 Dec 2012 09:42:49 +1100
>
> > On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> >> I'm not sure how this patchset should be dealt with (should 1st patch go
> >> through different tree than 2nd and 3rd?), so therefore it's RFC.
> >>
> >> Second patch makes rfc3686 template work with asynchronous block ciphers and
> >> third patch changes aesni-intel to use this template. First patch fixed problem
> >> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
> >> 2nd patch breaks aes-ctr with IPSEC.
> >
> > I think the easiest way is to have these patches go through Dave's
> > tree.
>
> Better yet, Steffen's IPSEC tree :-)
Of course :)
--
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
^ permalink raw reply
* [PATCH] sctp: make sctp_addr_wq_timeout_handler static
From: Stephen Hemminger @ 2012-12-29 4:18 UTC (permalink / raw)
To: Vlad Yasevich, Sridhar Samudrala, Neil Horman, David S. Miller
Cc: linux-sctp, netdev
Fix sparse warning about local function that should be static.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/sctp/protocol.c 2012-12-27 11:36:34.817072247 -0800
+++ b/net/sctp/protocol.c 2012-12-28 20:02:51.445778974 -0800
@@ -595,7 +595,7 @@ static void sctp_v4_ecn_capable(struct s
INET_ECN_xmit(sk);
}
-void sctp_addr_wq_timeout_handler(unsigned long arg)
+static void sctp_addr_wq_timeout_handler(unsigned long arg)
{
struct net *net = (struct net *)arg;
struct sctp_sockaddr_entry *addrw, *temp;
^ permalink raw reply
* [PATCH] tcp: make proc_tcp_fastopen_key static
From: Stephen Hemminger @ 2012-12-29 4:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Detected by sparse.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/sysctl_net_ipv4.c 2012-11-30 10:29:10.903478045 -0800
+++ b/net/ipv4/sysctl_net_ipv4.c 2012-12-28 20:05:49.687988892 -0800
@@ -232,8 +232,8 @@ static int ipv4_tcp_mem(ctl_table *ctl,
return 0;
}
-int proc_tcp_fastopen_key(ctl_table *ctl, int write, void __user *buffer,
- size_t *lenp, loff_t *ppos)
+static int proc_tcp_fastopen_key(ctl_table *ctl, int write, void __user *buffer,
+ size_t *lenp, loff_t *ppos)
{
ctl_table tbl = { .maxlen = (TCP_FASTOPEN_KEY_LENGTH * 2 + 10) };
struct tcp_fastopen_context *ctxt;
^ permalink raw reply
* [PATCH] skbuff: make __kmalloc_reserve static
From: Stephen Hemminger @ 2012-12-29 4:24 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev
Sparse detected case where this local function should be static.
It may even allow some compiler optimizations.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/skbuff.c 2012-12-28 19:46:31.967615872 -0800
+++ b/net/core/skbuff.c 2012-12-28 20:00:33.343165940 -0800
@@ -155,8 +155,9 @@ static void skb_under_panic(struct sk_bu
*/
#define kmalloc_reserve(size, gfp, node, pfmemalloc) \
__kmalloc_reserve(size, gfp, node, _RET_IP_, pfmemalloc)
-void *__kmalloc_reserve(size_t size, gfp_t flags, int node, unsigned long ip,
- bool *pfmemalloc)
+
+static void *__kmalloc_reserve(size_t size, gfp_t flags, int node,
+ unsigned long ip, bool *pfmemalloc)
{
void *obj;
bool ret_pfmemalloc = false;
^ permalink raw reply
* Re: [PATCH] sctp: make sctp_addr_wq_timeout_handler static
From: David Miller @ 2012-12-29 4:33 UTC (permalink / raw)
To: shemminger; +Cc: vyasevich, sri, nhorman, linux-sctp, netdev
In-Reply-To: <20121228201855.4275db64@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 28 Dec 2012 20:18:55 -0800
> Fix sparse warning about local function that should be static.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: make proc_tcp_fastopen_key static
From: David Miller @ 2012-12-29 4:33 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20121228202024.2d3dea76@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 28 Dec 2012 20:20:24 -0800
> Detected by sparse.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] skbuff: make __kmalloc_reserve static
From: David Miller @ 2012-12-29 4:33 UTC (permalink / raw)
To: shemminger; +Cc: edumazet, netdev
In-Reply-To: <20121228202428.5aa18a7b@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 28 Dec 2012 20:24:28 -0800
> Sparse detected case where this local function should be static.
> It may even allow some compiler optimizations.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* [PATCHv2 net-next] bridge: respect RFC2863 operational state
From: Stephen Hemminger @ 2012-12-29 4:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121228.152754.707370216340290808.davem@davemloft.net>
The bridge link detection should follow the operational state
of the lower device, rather than the carrier bit. This allows devices
like tunnels that are controlled by userspace control plane to work
with bridge STP link management.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
v2 - add more places and fix typo
net/bridge/br_if.c | 6 +++---
net/bridge/br_netlink.c | 5 ++++-
net/bridge/br_notify.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
4 files changed, 9 insertions(+), 6 deletions(-)
--- a/net/bridge/br_if.c 2012-12-27 22:30:53.634796003 -0800
+++ b/net/bridge/br_if.c 2012-12-28 19:54:14.198973683 -0800
@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
struct net_device *dev = p->dev;
struct net_bridge *br = p->br;
- if (netif_running(dev) && netif_carrier_ok(dev))
+ if (netif_running(dev) && netif_oper_up(dev))
p->path_cost = port_cost(dev);
if (!netif_running(br->dev))
return;
spin_lock_bh(&br->lock);
- if (netif_running(dev) && netif_carrier_ok(dev)) {
+ if (netif_running(dev) && netif_oper_up(dev)) {
if (p->state == BR_STATE_DISABLED)
br_stp_enable_port(p);
} else {
@@ -383,7 +383,7 @@ int br_add_if(struct net_bridge *br, str
spin_lock_bh(&br->lock);
changed_addr = br_stp_recalculate_bridge_id(br);
- if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
+ if (netif_running(dev) && netif_oper_up(dev) &&
(br->dev->flags & IFF_UP))
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);
--- a/net/bridge/br_notify.c 2012-12-27 22:30:23.547098173 -0800
+++ b/net/bridge/br_notify.c 2012-12-28 19:47:57.022761664 -0800
@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
break;
case NETDEV_UP:
- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
+ if (netif_running(br->dev) && netif_oper_up(dev)) {
spin_lock_bh(&br->lock);
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);
--- a/net/bridge/br_netlink.c 2012-12-27 11:36:34.813072288 -0800
+++ b/net/bridge/br_netlink.c 2012-12-28 19:52:24.180078602 -0800
@@ -181,8 +181,11 @@ static int br_set_port_state(struct net_
if (p->br->stp_enabled == BR_KERNEL_STP)
return -EBUSY;
+ /* if device is not up, change is not allowed
+ * if link is not present, only allowable state is disabled
+ */
if (!netif_running(p->dev) ||
- (!netif_carrier_ok(p->dev) && state != BR_STATE_DISABLED))
+ (!netif_oper_up(p->dev) && state != BR_STATE_DISABLED))
return -ENETDOWN;
p->state = state;
--- a/net/bridge/br_stp_if.c 2012-10-29 09:07:36.618530493 -0700
+++ b/net/bridge/br_stp_if.c 2012-12-28 19:53:37.207345191 -0800
@@ -54,7 +54,7 @@ void br_stp_enable_bridge(struct net_bri
br_config_bpdu_generation(br);
list_for_each_entry(p, &br->port_list, list) {
- if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
+ if (netif_running(p->dev) && netif_oper_up(p->dev))
br_stp_enable_port(p);
}
^ permalink raw reply
* Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 9:24 UTC (permalink / raw)
To: netdev; +Cc: vvs
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
We found a few nodes, where network works slow in containers.
For testing speed of TCP connections we use wget, which downloads iso
images from the internet.
wget in the new netns reports only 1.5 MB/s, but wget in the root netns
reports 33MB/s.
A few facts:
* Experiments shows that window size for CT traffic does not increases
up to ~900, however for host traffic window size increases up to ~14000
* packets are shuffled in the netns sometimes.
* tso/gro/gso changes on interfaces does not help
* issue was _NOT_ reproduced if kernel booted with maxcpus=1 or bnx2.disable_msi=1
I reduced steps to reproduce:
* Create a new network namespace "test" and a veth pair.
# ip netns add test
# ip link add name veth0 type veth peer name veth1
* Move veth1 into the netns test
# ip link set veth1 netns test
* Set ip address on veth1 and proper routing rules are added for this ip
in the root netns.
# ip link set up dev veth0; ip link set up dev veth0
# ip netns exec test ip a add REMOTE dev veth1
# ip netns exec test ip r a default via veth1
# ip r a REMOTE/32 via dev veth0
Tcpdump for both cases are attached to this message.
tcpdump.host - wget in the root netns
tcpdump.netns.host - tcpdump for the host device, wget in the new netns
tcpdump.netns.veth - tcpdump for the veth1 device, wget in the new netns
3.8-rc1 is used for experiments.
Do you have any ideas where is a problem?
[-- Attachment #2: tcpdump.host.gz --]
[-- Type: application/x-gzip, Size: 168126 bytes --]
[-- Attachment #3: tcpdump.netns.veth.gz --]
[-- Type: application/x-gzip, Size: 178809 bytes --]
[-- Attachment #4: tcpdump.netns.host.gz --]
[-- Type: application/x-gzip, Size: 178424 bytes --]
^ permalink raw reply
* Re: Panic: dma_map_area overflow 66 bytes on 3.7+
From: Martin Nybo Andersen @ 2012-12-29 10:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Michal Schmidt, linux-kernel, netdev
In-Reply-To: <1356724390.21409.641.camel@edumazet-glaptop>
On Friday 28 December 2012 20:53:10 Eric Dumazet wrote:
> On Fri, 2012-12-28 at 20:05 +0100, Martin Nybo Andersen wrote:
> > Hi list,
> >
> > Since the release of 3.7 my main computer has been panicking a couple of
> > times on both 3.7.0 and 3.7.1 because of a 'dma_map_area overflow xx bytes'.
> >
> > Example screen shot:
> > http://www.tweek.dk/panic.jpg
> >
> > I can reproduce it somewhat easily by visiting http://www.openstreetmap.org/
> > and zoom erratically with the scroll-button on the mouse.
> >
> > The panic seems to occur on line 229 of arch/x86/kernel/amd_gart_64.c, and
> > reverting commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd (r8169: use
> > unlimited DMA burst for TX) seems to fix the problem for me (at least I've
> > not been able to make it panic as before (yet)).
> >
> >
> > lspci -v:
> > 00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS480 Host Bridge (rev 01)
> > 00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI-X Root Port
> > 00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI Bridge
> > 00:12.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA
> > 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0)
> > 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1)
> > 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2)
> > 00:13.3 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3)
> > 00:13.4 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4)
> > 00:13.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI)
> > 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 13)
> > 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB600 IDE
> > 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)
> > 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge
> > 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge
> > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> > 02:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
> > 03:07.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)
> >
> >
> > Please tell, if more info is needed.
>
> Seems you have CONFIG_IOMMU_DEBUG, is it really what you want ?
That is true, I've enabled CONFIG_IOMMU_DEBUG.
If I want it? It seems like I don't... :-)
> It seems a bit strange we panic in this case
> ( panic_on_overflow = 1;)
I don't know much about IOMMUs, but if the alternative is trashed memory then
I'm in for it.
panic_on_overflow is set on lines 26--27 of arch/x86/kernel/pci-dma.c along
with force_iommu if CONFIG_IOMMU_DEBUG is enabled.
> You could try to add iommu=nopanic to your boot command : packet should
> be dropped, instead of panic.
I opt for disabling CONFIG_IOMMU_DEBUG, as it sets force_iommu as well.
If the only consequence of this is stats.tx_dropped being bumped not too
often, that's ok for me.
Thanks for the quick help! :-)
Regards,
Martin Nybo Andersen
^ permalink raw reply
* [patch net-next V3 00/15] net: introduce upper device lists and remove dev->master
From: Jiri Pirko @ 2012-12-29 10:38 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, bhutchings, faisal.latif, shemminger, fbl,
roland, sean.hefty, hal.rosenstock, fubar, andy, divy,
jitendra.kalsaria, sony.chacko, linux-driver, kaber, ursula.braun,
blaschka, schwidefsky, heiko.carstens, ebiederm, joe, amwang,
nhorman, john.r.fastabend, pablo
This is a V3 of a repost of my previous patchset:
"[patch net-next v2 00/15] net: introduce upper device lists and remove dev->master" fomr Aug 14
The discussion around
"[net-next] bonding: don't allow the master to become its slave"
forced me to think about upper<->lower device connections.
This patchset adds a possibility to record upper device linkage.
All upper<->lower devices are converted to use this mechanism right after.
That leads to dev->master removal because this info becomes redundant since
"master links" have the same value.
After all changes, there is no longer possible to do things as:
"bond->someotherdevice->samebond"
Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
in future by being able to get more appropriate info about l3 addresses.
v2->v3:
- removed recursion in __netdev_has_upper_dev()
- refreshed bits to be applicable on current net-next
v1->v2:
- s/unique/master/ better naming + stays closer to the past
- fixed vlan err goto
- original patch 15 (WARN_ON change) is squashed into the first patch
Jiri Pirko (15):
net: introduce upper device lists
macvlan: add link to upper device
vlan: add link to upper device
rtnetlink: remove usage of dev->master
team: remove usage of netdev_set_master()
bridge: remove usage of netdev_set_master()
netpoll: remove usage of dev->master
cxgb3: remove usage of dev->master
qlcnic: guard __vlan_find_dev_deep() by rcu_read_lock
qeth: ensure that __vlan_find_dev_deep() is called with rcu_read_lock
vlan: remove usage of dev->master in __vlan_find_dev_deep()
nes: remove usage of dev->master
bonding: remove usage of dev->master
net: remove no longer used netdev_set_bond_master() and
netdev_set_master()
net: kill dev->master
drivers/infiniband/hw/nes/nes.c | 8 +-
drivers/infiniband/hw/nes/nes_cm.c | 2 +-
drivers/net/bonding/bond_3ad.c | 30 +--
drivers/net/bonding/bond_alb.c | 6 +-
drivers/net/bonding/bond_main.c | 94 +++++---
drivers/net/bonding/bonding.h | 14 +-
drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 11 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +
drivers/net/macvlan.c | 9 +-
drivers/net/team/team.c | 13 +-
drivers/s390/net/qeth_l3_main.c | 21 +-
include/linux/netdevice.h | 22 +-
net/8021q/vlan.c | 10 +-
net/8021q/vlan_core.c | 18 +-
net/bridge/br_if.c | 6 +-
net/core/dev.c | 262 ++++++++++++++++++---
net/core/netpoll.c | 9 +-
net/core/rtnetlink.c | 70 +++---
18 files changed, 425 insertions(+), 182 deletions(-)
--
1.8.0
^ 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