* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Cong Wang @ 2014-02-11 4:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, Cong Wang, netdev, Patrick McHardy,
David S. Miller
In-Reply-To: <1392092120.6615.64.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Feb 10, 2014 at 8:15 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-02-11 at 03:40 +0100, Hannes Frederic Sowa wrote:
>
>> Setting up a macvlan and moving it into another namespace without moving
>> the parent device is a nice feature. I am not an administrator, so I don't
>> use that stuff often, but given you can easily spawn namespaces and put
>> applications into them, one of the easiest things to connect those to
>> local network without routing over veth and such is the macvlan interface.
>
> Exactly.
>
Exactly broken by design.
IFA_LINK is an ifindex, ifindex is per-netns. macvlan should not use IFA_LINK.
^ permalink raw reply
* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Eric Dumazet @ 2014-02-11 4:15 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Cong Wang, Cong Wang, netdev, Patrick McHardy, David S. Miller
In-Reply-To: <20140211024009.GD11150@order.stressinduktion.org>
On Tue, 2014-02-11 at 03:40 +0100, Hannes Frederic Sowa wrote:
> Setting up a macvlan and moving it into another namespace without moving
> the parent device is a nice feature. I am not an administrator, so I don't
> use that stuff often, but given you can easily spawn namespaces and put
> applications into them, one of the easiest things to connect those to
> local network without routing over veth and such is the macvlan interface.
Exactly.
^ permalink raw reply
* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Eric Dumazet @ 2014-02-11 4:14 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Patrick McHardy, David S. Miller, Cong Wang
In-Reply-To: <1392082593-7742-1-git-send-email-xiyou.wangcong@gmail.com>
On Mon, 2014-02-10 at 17:36 -0800, Cong Wang wrote:
> From: Cong Wang <cwang@twopensource.com>
>
> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>
> There is no point to allow moving a macvlan device to
> another namespace while the lower device is still in
> this namespace. tunnels already set this flag.
What do you mean ?
This is probably one of the needed/useful feature of macvlan !
^ permalink raw reply
* Re: linux 3.13: problems with isatap tunnel device and UFO
From: Hannes Frederic Sowa @ 2014-02-11 2:44 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: netdev
In-Reply-To: <1581659.JtJ1UQaXJr@h2o.as.studentenwerk.mhn.de>
On Sun, Feb 09, 2014 at 12:17:15AM +0100, Wolfgang Walter wrote:
> host A (which shows the problem with kernel 3.13):
>
> $ ip addr ls eth0
> 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
> group default qlen 1000
> link/ether 11:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 2001:1111:2222:aaaa:0:5efe:c0a8:101/120 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::1322:33ff:fe44:5566/64 scope link
> valid_lft forever preferred_lft forever
What driver does this interface use?
ethtool -i eth0
Greetings,
Hannes
^ permalink raw reply
* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Hannes Frederic Sowa @ 2014-02-11 2:40 UTC (permalink / raw)
To: Cong Wang; +Cc: Cong Wang, netdev, Patrick McHardy, David S. Miller
In-Reply-To: <CAHA+R7N2rxt5vyF+i8mi04dJaLk5bCgMAZOCexOLULLcQ-mT6w@mail.gmail.com>
On Mon, Feb 10, 2014 at 06:25:51PM -0800, Cong Wang wrote:
> On Mon, Feb 10, 2014 at 5:45 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Mon, Feb 10, 2014 at 05:36:33PM -0800, Cong Wang wrote:
> >> From: Cong Wang <cwang@twopensource.com>
> >>
> >> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
> >>
> >> There is no point to allow moving a macvlan device to
> >> another namespace while the lower device is still in
> >> this namespace. tunnels already set this flag.
> >
> > Can't we solve this somehow differently, like not showing anything at all
> > etc.? I guess this is a feature some people use and haven't noticed yet.
> >
>
> I don't understand what you mean by "not showing anything at all".
> I assume you mean mac1@xxx, not matter whether we show xxx
> here, mac1 relies on xxx to function.
Sorry, I have no idea how to resolve this easily, maybe set the ifindex to
something generic. I'll try to think about it.
Maybe revserve an id and install a generic name for it, so old software
doesn't get confused.
> Please give a real use case rather than just guessing, I don't think
> there is any valid case until we support moving multiple devices into
> a netns atomically.
Setting up a macvlan and moving it into another namespace without moving
the parent device is a nice feature. I am not an administrator, so I don't
use that stuff often, but given you can easily spawn namespaces and put
applications into them, one of the easiest things to connect those to
local network without routing over veth and such is the macvlan interface.
Greetings,
Hannes
^ permalink raw reply
* RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel
From: hayeswang @ 2014-02-11 2:36 UTC (permalink / raw)
To: 'Grant Grundler'
Cc: inky.yoo, 'netdev', 'David Miller'
In-Reply-To: <CANEJEGtzUF+rdSqgTHL0BmsDbCeoWki=aAWZwSx-dZ24jQ=nVg@mail.gmail.com>
Grant Grundler [mailto:grundler@google.com]
> Sent: Tuesday, February 11, 2014 9:39 AM
> To: Hayes Wang
> Cc: inky.yoo@samsung.com; netdev; David Miller
> Subject: RTL8153 fails to get link after applying c7de7dec2
> to 3.8 kernel
>
> Hi Hayes,
> "r8152: ecm and vendor modes coexist" patch prevents RTL8153 device
> from establishing a link in the backport I've worked on for
> chromeos-3.8 kernel. IIRC, r815x driver claims this device. Without
> this patch, r8152 is able to establish a link with RTL8153 device.
>
> This was the last patch in the series of 40 patches that I
> cherry-picked and r8152 driver seems to "basically" work WITHOUT this
> last patch. I've not tested much yet...but DHCP worked and I'm able
> to run netperf tests. I've not investigated why this patch fails and
> probably won't.
>
> If you have opportunity, can you confirm RTL8153 devices work for you
> with any recent upstream kernel?
I had tested the patch before I sent it, and I didn't see any problem.
I would test the RTL8153 again with kernel 3.14-RC2.
Does it work if you unplug and plug the dangle again?
Best Regards,
Hayes
^ permalink raw reply
* Re: xfrm: is pmtu broken with ESP tunneling?
From: Hannes Frederic Sowa @ 2014-02-11 2:32 UTC (permalink / raw)
To: Ortwin Glück; +Cc: linux-kernel, netdev
In-Reply-To: <52F890D2.2060109@odi.ch>
Hi!
On Mon, Feb 10, 2014 at 09:41:54AM +0100, Ortwin Glück wrote:
> I am using Openswan to configure an IPSec VPN (using the xfrm/netkey
> backend). Large HTTP POST requests from the client seem to get stuck,
> because the outgoing packets are 1530 bytes (before being wrapped into
> ESP packets). The problem goes away by setting sysctl
> net.ipv4.ip_no_pmtu_disc=1.
This setting will shrink the path mtu to min_pmtu when a frag needed icmp is
received. It sounds like we calculate the path mtu incorreclty in case of
fragmentation.
> May have something to do with it:
> The tunneled network is 10.6.6.6/32 and I am SNAT'ing some destinations
> to that IP, so they get routed through the tunnel. Any other networks
> are not to go through the tunnel.
>
> iptables -t nat -A POSTROUTING -d "${R}" -j SNAT --to-source 10.6.6.6
>
> It seems quite clear to me that xfrm is doing something wrong here.
Can you send a ip route get <ip> to the problematic target to see how
far off the calculated value is?
Thanks,
Hannes
^ permalink raw reply
* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Cong Wang @ 2014-02-11 2:25 UTC (permalink / raw)
To: Cong Wang, netdev, Patrick McHardy, David S. Miller, Cong Wang
In-Reply-To: <20140211014535.GA11150@order.stressinduktion.org>
On Mon, Feb 10, 2014 at 5:45 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Mon, Feb 10, 2014 at 05:36:33PM -0800, Cong Wang wrote:
>> From: Cong Wang <cwang@twopensource.com>
>>
>> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>>
>> There is no point to allow moving a macvlan device to
>> another namespace while the lower device is still in
>> this namespace. tunnels already set this flag.
>
> Can't we solve this somehow differently, like not showing anything at all
> etc.? I guess this is a feature some people use and haven't noticed yet.
>
I don't understand what you mean by "not showing anything at all".
I assume you mean mac1@xxx, not matter whether we show xxx
here, mac1 relies on xxx to function.
Please give a real use case rather than just guessing, I don't think
there is any valid case until we support moving multiple devices into
a netns atomically.
^ permalink raw reply
* Re: [PATCH net] net: Clear local_df only if crossing namespace.
From: Hannes Frederic Sowa @ 2014-02-11 2:11 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, netdev, Templin, Fred L, Nicolas Dichtel
In-Reply-To: <CALnjE+qiRbLWBJyhig7DFETRLRgAZHqJqUEYGVuJ6nXc7cPguw@mail.gmail.com>
On Mon, Feb 10, 2014 at 01:00:14PM -0800, Pravin Shelar wrote:
> On Fri, Feb 7, 2014 at 4:58 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > May I know because of wich vport, vxlan or gre, you did this change?
> >
> It affects both gre and vxlan.
Ok, thanks.
> > I am feeling a bit uncomfortable handling remote and local packets that
> > differently on lower tunnel output (local_df is mostly set on locally
> > originating packets).
>
> For ip traffic it make sense to turn on local_df only for local
> traffic, since for remote case we can send icmp (frag-needed) back to
> source. No such thing exist for OVS tunnels. ICMP packet are not
> returned to source for the tunnels. That is why to be on safe side,
> local_df is turned on for tunnels in OVS.
I have a proposal:
I don't like it that much because of the many arguments. But I currently
don't see another easy solution. Maybe we should make bool xnet an enum and
test with bitops?
I left the clearing of local_df in skb_scrub_packet as we need it for the
dev_forward_skb case and it should be done that in any case.
This diff is slightly compile tested. ;)
I can test and make proper submit if you agree.
What do you think?
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 026a313..630e72f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1657,7 +1657,7 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
return err;
return iptunnel_xmit(rt, skb, src, dst, IPPROTO_UDP, tos, ttl, df,
- false);
+ false, false);
}
EXPORT_SYMBOL_GPL(vxlan_xmit_skb);
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 48ed75c..8863002 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -154,7 +154,8 @@ static inline u8 ip_tunnel_ecn_encap(u8 tos, const struct iphdr *iph,
int iptunnel_pull_header(struct sk_buff *skb, int hdr_len, __be16 inner_proto);
int iptunnel_xmit(struct rtable *rt, struct sk_buff *skb,
__be32 src, __be32 dst, __u8 proto,
- __u8 tos, __u8 ttl, __be16 df, bool xnet);
+ __u8 tos, __u8 ttl, __be16 df, bool xnet,
+ bool clear_local_df);
struct sk_buff *iptunnel_handle_offloads(struct sk_buff *skb, bool gre_csum,
int gso_type_mask);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8f519db..5773681 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3903,12 +3903,13 @@ EXPORT_SYMBOL(skb_try_coalesce);
*/
void skb_scrub_packet(struct sk_buff *skb, bool xnet)
{
- if (xnet)
+ if (xnet) {
skb_orphan(skb);
+ skb->local_df = 0;
+ }
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->skb_iif = 0;
- skb->local_df = 0;
skb_dst_drop(skb);
skb->mark = 0;
secpath_reset(skb);
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index c0e3cb7..2922ec9 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -721,7 +721,8 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
}
err = iptunnel_xmit(rt, skb, fl4.saddr, fl4.daddr, protocol,
- tos, ttl, df, !net_eq(tunnel->net, dev_net(dev)));
+ tos, ttl, df, !net_eq(tunnel->net, dev_net(dev)),
+ true);
iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
return;
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 6156f4e..93beb04 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -48,13 +48,16 @@
int iptunnel_xmit(struct rtable *rt, struct sk_buff *skb,
__be32 src, __be32 dst, __u8 proto,
- __u8 tos, __u8 ttl, __be16 df, bool xnet)
+ __u8 tos, __u8 ttl, __be16 df, bool xnet,
+ bool clear_df)
{
int pkt_len = skb->len;
struct iphdr *iph;
int err;
skb_scrub_packet(skb, xnet);
+ if (clear_df)
+ skb->local_df = 0;
skb_clear_hash(skb);
skb_dst_set(skb, &rt->dst);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 3dfbcf1..cc0be0e 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -974,7 +974,7 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
}
err = iptunnel_xmit(rt, skb, fl4.saddr, fl4.daddr, IPPROTO_IPV6, tos,
- ttl, df, !net_eq(tunnel->net, dev_net(dev)));
+ ttl, df, !net_eq(tunnel->net, dev_net(dev)), true);
iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
return NETDEV_TX_OK;
^ permalink raw reply related
* Re: [PATCH] 6lowpan: fix lockdep splats
From: David Miller @ 2014-02-11 1:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: alex.aring, netdev
In-Reply-To: <1392061355.6615.52.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Feb 2014 11:42:35 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> When a device ndo_start_xmit() calls again dev_queue_xmit(),
> lockdep can complain because dev_queue_xmit() is re-entered and the
> spinlocks protecting tx queues share a common lockdep class.
>
> Same issue was fixed for bonding/l2tp/ppp in commits
>
> 0daa2303028a6 ("[PATCH] bonding: lockdep annotation")
> 49ee49202b4ac ("bonding: set qdisc_tx_busylock to avoid LOCKDEP splat")
> 23d3b8bfb8eb2 ("net: qdisc busylock needs lockdep annotations ")
> 303c07db487be ("ppp: set qdisc_tx_busylock to avoid LOCKDEP splat ")
>
> Reported-by: Alexander Aring <alex.aring@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Alexander Aring <alex.aring@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] alx: add missing stats_lock spinlock init
From: David Miller @ 2014-02-11 1:51 UTC (permalink / raw)
To: jogreene; +Cc: netdev
In-Reply-To: <1392060844-30995-1-git-send-email-jogreene@redhat.com>
From: John Greene <jogreene@redhat.com>
Date: Mon, 10 Feb 2014 14:34:04 -0500
> Trivial fix for init time stack trace occuring in
> alx_get_stats64 upon start up. Should have been part of
> commit adding the spinlock:
> f1b6b106 alx: add alx_get_stats64 operation
>
> Signed-off-by: John Greene <jogreene@redhat.com>
Applied, thank you.
^ permalink raw reply
* [PATCH v2 1/2] sctp: fix a missed .data initialization
From: Wang Weidong @ 2014-02-11 1:49 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev
In-Reply-To: <1392083346-9420-1-git-send-email-wangweidong1@huawei.com>
As commit 3c68198e75111a90("sctp: Make hmac algorithm selection for
cookie generation dynamic"), we miss the .data initialization.
If we don't use the net_namespace, the problem that parts of the
sysctl configuration won't be isolation and won't occur.
In sctp_sysctl_net_register(), we register the sysctl for each
net, in the for(), we use the 'table[i].data' as check condition, so
when the 'i' is the index of sctp_hmac_alg, the data is NULL, then
break. So add the .data initialization.
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
net/sctp/sysctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index b0565af..2ddb401 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -152,6 +152,7 @@ static struct ctl_table sctp_net_table[] = {
},
{
.procname = "cookie_hmac_alg",
+ .data = &init_net.sctp.sctp_hmac_alg,
.maxlen = 8,
.mode = 0644,
.proc_handler = proc_sctp_do_hmac_alg,
--
1.7.12
^ permalink raw reply related
* [PATCH v2 0/2] sctp: fix a problem with net_namespace
From: Wang Weidong @ 2014-02-11 1:49 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev
fix a problem with net_namespace, and optimize
the sctp_sysctl_net_register.
v1 -> v2:
-patch1: add Neil's ACK.
Wang Weidong (2):
sctp: fix a missed .data initialization
sctp: optimize the sctp_sysctl_net_register
net/sctp/sysctl.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--
1.7.12
^ permalink raw reply
* [PATCH v2 2/2] sctp: optimize the sctp_sysctl_net_register
From: Wang Weidong @ 2014-02-11 1:49 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev
In-Reply-To: <1392083346-9420-1-git-send-email-wangweidong1@huawei.com>
Here, when the net is init_net, we needn't to kmemdup the ctl_table
again. So add a check for net. Also we can save some memory.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
net/sctp/sysctl.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index 2ddb401..b65396b 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -403,15 +403,17 @@ static int proc_sctp_do_rto_max(struct ctl_table *ctl, int write,
int sctp_sysctl_net_register(struct net *net)
{
- struct ctl_table *table;
- int i;
+ struct ctl_table *table = sctp_net_table;
- table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
- if (!table)
- return -ENOMEM;
+ if (!net_eq(net, &init_net)) {
+ int i;
+ table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
- for (i = 0; table[i].data; i++)
- table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
+ for (i = 0; table[i].data; i++)
+ table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
+ }
net->sctp.sysctl_header = register_net_sysctl(net, "net/sctp", table);
return 0;
--
1.7.12
^ permalink raw reply related
* Re: Latest version of zero-copy fix
From: David Miller @ 2014-02-11 1:48 UTC (permalink / raw)
To: ryao; +Cc: netdev
In-Reply-To: <52F97D5F.4040100@gentoo.org>
From: Richard Yao <ryao@gentoo.org>
Date: Mon, 10 Feb 2014 20:31:11 -0500
> 1. We allocate a temporary buffer with vmalloc().
> 2. We read the module into that buffer.
Ok, I didn't catch this, I'll apply your patch thanks!
^ permalink raw reply
* Re: [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Hannes Frederic Sowa @ 2014-02-11 1:45 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Patrick McHardy, David S. Miller, Cong Wang
In-Reply-To: <1392082593-7742-1-git-send-email-xiyou.wangcong@gmail.com>
On Mon, Feb 10, 2014 at 05:36:33PM -0800, Cong Wang wrote:
> From: Cong Wang <cwang@twopensource.com>
>
> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>
> There is no point to allow moving a macvlan device to
> another namespace while the lower device is still in
> this namespace. tunnels already set this flag.
Can't we solve this somehow differently, like not showing anything at all
etc.? I guess this is a feature some people use and haven't noticed yet.
Greetings,
Hannes
^ permalink raw reply
* RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel
From: Grant Grundler @ 2014-02-11 1:38 UTC (permalink / raw)
To: Hayes Wang; +Cc: inky.yoo, netdev, David Miller
Hi Hayes,
"r8152: ecm and vendor modes coexist" patch prevents RTL8153 device
from establishing a link in the backport I've worked on for
chromeos-3.8 kernel. IIRC, r815x driver claims this device. Without
this patch, r8152 is able to establish a link with RTL8153 device.
This was the last patch in the series of 40 patches that I
cherry-picked and r8152 driver seems to "basically" work WITHOUT this
last patch. I've not tested much yet...but DHCP worked and I'm able
to run netperf tests. I've not investigated why this patch fails and
probably won't.
If you have opportunity, can you confirm RTL8153 devices work for you
with any recent upstream kernel?
I'm testing with a Realtek branded device that lsusb says is:
Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
cheers
grant
git log drivers/net/usb/r8152.c
...
commit c7de7dec2ff2528ec630c55e68c25bd9d972b677
Author: hayeswang <hayeswang@realtek.com>
Date: Wed Jan 15 10:42:16 2014 +0800
r8152: ecm and vendor modes coexist
Remove the limitation that the ecm and r8152 drivers couldn't coexist.
- Remove the devices from the blacklist of relative drivers.
- Remove usb_driver_set_configuration() from r8152 driver.
- Modify the id_table of the r8152 driver for the vendor mode only.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [Patch net] macvlan: add NETIF_F_NETNS_LOCAL flag
From: Cong Wang @ 2014-02-11 1:36 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy, David S. Miller, Cong Wang, Cong Wang
From: Cong Wang <cwang@twopensource.com>
BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
There is no point to allow moving a macvlan device to
another namespace while the lower device is still in
this namespace. tunnels already set this flag.
Cc: Patrick McHardy <kaber@trash.net>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 8433de4..9bc3b13 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -539,7 +539,7 @@ static int macvlan_init(struct net_device *dev)
dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
(lowerdev->state & MACVLAN_STATE_MASK);
dev->features = lowerdev->features & MACVLAN_FEATURES;
- dev->features |= NETIF_F_LLTX;
+ dev->features |= NETIF_F_LLTX | NETIF_F_NETNS_LOCAL;
dev->gso_max_size = lowerdev->gso_max_size;
dev->iflink = lowerdev->ifindex;
dev->hard_header_len = lowerdev->hard_header_len;
@@ -699,7 +699,7 @@ static netdev_features_t macvlan_fix_features(struct net_device *dev,
features = netdev_increment_features(vlan->lowerdev->features,
features,
mask);
- features |= NETIF_F_LLTX;
+ features |= NETIF_F_LLTX | NETIF_F_NETNS_LOCAL;
return features;
}
^ permalink raw reply related
* Re: Latest version of zero-copy fix
From: Richard Yao @ 2014-02-11 1:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140210.152150.574073124161003333.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
On 02/10/2014 06:21 PM, David Miller wrote:
>
> So now the patch only tests is_vmalloc_addr(), did you test this
> version with the situation that triggers the given backtrace?
>
> [<ffffffff814878ce>] p9_virtio_zc_request+0x45e/0x510
> [<ffffffff814814ed>] p9_client_zc_rpc.constprop.16+0xfd/0x4f0
> [<ffffffff814839dd>] p9_client_read+0x15d/0x240
> [<ffffffff811c8440>] v9fs_fid_readn+0x50/0xa0
> [<ffffffff811c84a0>] v9fs_file_readn+0x10/0x20
> [<ffffffff811c84e7>] v9fs_file_read+0x37/0x70
> [<ffffffff8114e3fb>] vfs_read+0x9b/0x160
> [<ffffffff81153571>] kernel_read+0x41/0x60
> [<ffffffff810c83ab>] copy_module_from_fd.isra.34+0xfb/0x180
>
> This is reading from v9fs into a module address.
>
> It's going generate the same backtrace with your fix.
>
> I don't think the situation was sufficiently explained to Linus. In
> fact, I didn't see the above backtrace mentioned at all.
>
I have tested it against Linux 3.13.0 and I can confirm that it solves
the problem. In fact, this was the original patch in December before I
made the last minute change to is_module_or_vmalloc_addr() only after
deciding that is_vmalloc_addr() was not general enough.
Linus' response had two key points. Linus' first point was that my
generalization of is_vmalloc_addr() to is_module_or_vmalloc_addr() was
unnecessary to fix this problem because the order of events is as follows:
1. We allocate a temporary buffer with vmalloc().
2. We read the module into that buffer.
3. We copy the module from that buffer into its final location.
Linus' second point was that my generalization permitted IO to be done
to a region of memory where IO operations should never be done. When I
wrote this back in December, I wanted to write as general a fix as
possible because Alexander Graf had pointed out to me that there had
Will Deacon had written a patch that should have included this, but
neglected it and I was afraid that that would become a cycle.
Linus' clear explanation of why this is a bad idea changed my mind, so I
submitted the original form of this patch with an updated commit message.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 01/34] bnx2: Use pci_enable_msix_range()
From: Bjorn Helgaas @ 2014-02-11 1:08 UTC (permalink / raw)
To: David Miller; +Cc: agordeev, linux-kernel, mchan, netdev, linux-pci
In-Reply-To: <20140211003814.GC12851@google.com>
On Mon, Feb 10, 2014 at 05:38:14PM -0700, Bjorn Helgaas wrote:
> On Fri, Jan 31, 2014 at 01:30:51PM -0800, David Miller wrote:
> >
> > Please submit this patch series when the net-next tree opens back up,
> > I'm only accepting bug fixes at this time.
> >
> > Also, please always provide a proper "00/NN" openning posting for a
> > patch series, that gives background and high level information about
> > what your patch series is trying to achieve and how it achieves it.
> >
> > That way people reviewing the patches know what to expect, and why,
> > and I have exactly one posting to reply to if I apply the whole
> > series.
>
> I *think* this whole series applies to drivers/net (the usual patch sending
> tools like "stg mail" insert the diffstat automatically in the 00/nn
> message), and it sounds like David is willing to apply them via his tree,
> so I'm ignoring these for now. Let me know if you need me to do anything.
I skimmed these and the scsi patches, and I think you were right in
proposing an MSI-X enable function that takes a single "number of vectors"
argument, in addition to pci_enable_msix_range(), which takes a minimum and
a maximum. Obviously the pci_enable_msix_fixed() or whatever could be a
simple #define wrapper or something.
Of the fifty-some net and scsi patches, I counted 23 that use the min ==
max pattern, and it seems a shame to have to repeat that expression.
BTW, I noticed that Documentation/PCI/MSI-HOWTO.txt uses
pci_enable_msi_range() in some of the examples that are really talking
about pci_enable_msix_range() (4.3.1.1 and 4.3.1.2, at least).
Bjorn
^ permalink raw reply
* Re: [PATCH net] bonding: remove unwanted bond lock for enslave processing
From: David Miller @ 2014-02-11 0:55 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, vfalico, andy, netdev
In-Reply-To: <52F88EF7.606@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Mon, 10 Feb 2014 16:33:59 +0800
> The bond enslave processing don't hold bond->lock anymore,
> so release an unlocked rw lock will cause warning message,
> remove the unwanted read_unlock(&bond->lock).
>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Veaceslav Falico <vfalico@redhat.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support
From: David Miller @ 2014-02-11 0:53 UTC (permalink / raw)
To: liujunliang_ljl
Cc: joe, horms, romieu, gregkh, netdev, linux-usb, linux-kernel,
sunhecheng
In-Reply-To: <1392013902-4875-1-git-send-email-liujunliang_ljl@163.com>
From: liujunliang_ljl@163.com
Date: Mon, 10 Feb 2014 14:31:42 +0800
> From: Liu Junliang <liujunliang_ljl@163.com>
>
>
> Signed-off-by: Liu Junliang <liujunliang_ljl@163.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 01/34] bnx2: Use pci_enable_msix_range()
From: Bjorn Helgaas @ 2014-02-11 0:38 UTC (permalink / raw)
To: David Miller; +Cc: agordeev, linux-kernel, mchan, netdev, linux-pci
In-Reply-To: <20140131.133051.483295479425700960.davem@davemloft.net>
On Fri, Jan 31, 2014 at 01:30:51PM -0800, David Miller wrote:
>
> Please submit this patch series when the net-next tree opens back up,
> I'm only accepting bug fixes at this time.
>
> Also, please always provide a proper "00/NN" openning posting for a
> patch series, that gives background and high level information about
> what your patch series is trying to achieve and how it achieves it.
>
> That way people reviewing the patches know what to expect, and why,
> and I have exactly one posting to reply to if I apply the whole
> series.
I *think* this whole series applies to drivers/net (the usual patch sending
tools like "stg mail" insert the diffstat automatically in the 00/nn
message), and it sounds like David is willing to apply them via his tree,
so I'm ignoring these for now. Let me know if you need me to do anything.
Bjorn
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-02-10 23:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: Oleksij Rempel, Richard Weinberger, Jonathan Bither,
OpenWrt Development List, Hauke Mehrtens, Jiri Slaby,
Nick Kossifidis, Luis R. Rodriguez, John W. Linville,
open list:ATHEROS ATH5K WIR..., open list:ATHEROS ATH5K WIR...,
open, list@hauke-m.de:NETWORKING DRIVERS, open list,
antonynpavlov@gmail.com
In-Reply-To: <CAGVrzcYnECx5Q=i+m6qZn29y4JALDpw5SWoUNP-S6HgPR3_ygQ@mail.gmail.com>
2014-02-11 2:37 GMT+04:00 Florian Fainelli <florian@openwrt.org>:
> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>:
>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>:
>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
>>>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>>>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>>>>>> The symbol is an orphan, get rid of it.
>>>>>>>
>>>>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>>>>> ---
>>>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>>>>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>>>>>
>>>>>>
>>>>>> This code is used in OpenWrt with an out of tree arch code for the
>>>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>>>>>> this code to mainline Linux kernel, because of lack of time/interest.
>>>>>
>>>>> Sorry, we don't maintain out of tree code.
>>>>>
>>>>
>>>> Oleksij, Jonathan do you still working to make ar231x devices work
>>>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
>>>> team would like to add upstream support?
>>>>
>>>> 1. https://lkml.org/lkml/2013/5/13/321
>>>> 2. https://lkml.org/lkml/2013/5/13/358
>>>>
>>>
>>> Hi,
>>> my current target was to provide barebox and openocd support.
>>> - ar2313 is already upstream on barebox.
>>> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov.
>>> - openocd (EJTAG) support is ready and i'll push it ASUP.
>>>
>> WOW, Impressive.
>
> That's a nice toy project, although since there are is an existing
> bootloader with sources, I would have shifted the priority towards
> getting the kernel support merged such that the bootloader can be used
> for something. BTW I sent a few devices to Jonathan, not sure if he
> ever got those...
>
>>
>>> I hope Jonathan do kernel part. If not, i can provide some work, since i
>>> have testing boards and expiriance on this hardware.
>>>
>> If you need, I can test kernel part, or even do some porting work. I
>> have some AR231x based boards, e.g. Ubnt LS2 and NS2.
>
> I guess you could start splitting the OpenWrt patches into a format
> that makes them suitable for being merged upstream and starting with
> the MIPS parts. There might be a bunch of checkpatch.pl cleanup work
> to do before getting those submitted.
I will do that if Jonathan does not have a working solution, which he
would like to push upstream. So, let's wait for his reply.
--
BR,
Sergey
^ permalink raw reply
* Re: [PATCH] tcp: tsq: fix nonagle handling
From: David Miller @ 2014-02-10 23:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, john.ogness, thomas
In-Reply-To: <1392000011.6615.15.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 09 Feb 2014 18:40:11 -0800
> From: John Ogness <john.ogness@linutronix.de>
>
> Commit 46d3ceabd8d9 ("tcp: TCP Small Queues") introduced a possible
> regression for applications using TCP_NODELAY.
>
> If TCP session is throttled because of tsq, we should consult
> tp->nonagle when TX completion is done and allow us to send additional
> segment, especially if this segment is not a full MSS.
> Otherwise this segment is sent after an RTO.
>
> [edumazet] : Cooked the changelog, added another fix about testing
> sk_wmem_alloc twice because TX completion can happen right before
> setting TSQ_THROTTLED bit.
>
> This problem is particularly visible with recent auto corking,
> but might also be triggered with low tcp_limit_output_bytes
> values or NIC drivers delaying TX completion by hundred of usec,
> and very low rtt.
>
> Thomas Glanzmann for example reported an iscsi regression, caused
> by tcp auto corking making this bug quite visible.
>
> Fixes: 46d3ceabd8d9 ("tcp: TCP Small Queues")
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
Applied and queued up for -stable, thanks!
^ 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