* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-13 0:33 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, Yuchung Cheng, netdev
In-Reply-To: <CAGK4HS_SpdECk_KCu98Z1X9W02G9j9u7QE9B6qHEnTXLeZbqgA@mail.gmail.com>
On Fri, Nov 9, 2012 at 12:54 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
> On 9 November 2012 12:27, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Fri, 2012-11-09 at 12:17 -0800, Vincent Li wrote:
>>
>>> I have tried to run fresh build net-next, for some reason the build
>>> stops ssh service from starting up, tried 3.7.0-rc4 too, same issue. I
>>> don't know if it is new kernel bug or ubuntu upstart bug, but that is
>>> another issue.
>>>
>>
>> Not sure Ubuntu 10.04 binaries can run a 3.7 kernel.
>>
>> Some bug fixes in kernel need bug fixes in userland.
>>
>> You could try a bisection ?
>>
> I saw the same issue with Ubuntu starting around 3.7.0-rc1 but 3.6
> was fine if I recall. (I did a partial bisection but was not sure it
> was a kernel issue)
> sshd would not start up on boot and I 'fixed' it by adding the
> following in /etc/rc.local since I assumed it was a userspace issue.
>
> if [ ! -d /var/run/sshd ]; then
> mkdir /var/run/sshd
> chmod 0755 /var/run/sshd
> fi
> /usr/sbin/sshd
>
>
> Thanks,
> Vijay
Hi Vijay,
just FYI, I filed a bug report in ubuntu and it appears to be a kernel
commit breaks the user space code that still using deprecated kernel
knobs oom_adj.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1077248
commit 01dc52ebdf472f77cca623ca693ca24cfc0f1bbe
Author: Davidlohr Bueso <dave@gnu.org>
Date: Mon Oct 8 16:29:30 2012 -0700
oom: remove deprecated oom_adj
The deprecated /proc/<pid>/oom_adj is scheduled for removal this month.
^ permalink raw reply
* [PATCH 2/3] netfilter: nf_nat: use PTR_RET
From: pablo @ 2012-11-13 0:06 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1352765203-4160-1-git-send-email-pablo@netfilter.org>
From: Wu Fengguang <fengguang.wu@intel.com>
Use PTR_RET rather than if(IS_ERR(...)) + PTR_ERR
Generated by: coccinelle/api/ptr_ret.cocci
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/iptable_nat.c | 4 +---
net/ipv6/netfilter/ip6table_nat.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/netfilter/iptable_nat.c b/net/ipv4/netfilter/iptable_nat.c
index 9e0ffaf..8d65b74 100644
--- a/net/ipv4/netfilter/iptable_nat.c
+++ b/net/ipv4/netfilter/iptable_nat.c
@@ -274,9 +274,7 @@ static int __net_init iptable_nat_net_init(struct net *net)
return -ENOMEM;
net->ipv4.nat_table = ipt_register_table(net, &nf_nat_ipv4_table, repl);
kfree(repl);
- if (IS_ERR(net->ipv4.nat_table))
- return PTR_ERR(net->ipv4.nat_table);
- return 0;
+ return PTR_RET(net->ipv4.nat_table);
}
static void __net_exit iptable_nat_net_exit(struct net *net)
diff --git a/net/ipv6/netfilter/ip6table_nat.c b/net/ipv6/netfilter/ip6table_nat.c
index e418bd6..4c8219e 100644
--- a/net/ipv6/netfilter/ip6table_nat.c
+++ b/net/ipv6/netfilter/ip6table_nat.c
@@ -275,9 +275,7 @@ static int __net_init ip6table_nat_net_init(struct net *net)
return -ENOMEM;
net->ipv6.ip6table_nat = ip6t_register_table(net, &nf_nat_ipv6_table, repl);
kfree(repl);
- if (IS_ERR(net->ipv6.ip6table_nat))
- return PTR_ERR(net->ipv6.ip6table_nat);
- return 0;
+ return PTR_RET(net->ipv6.ip6table_nat);
}
static void __net_exit ip6table_nat_net_exit(struct net *net)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] netfilter updates for net-next
From: pablo @ 2012-11-13 0:06 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi David,
The following three patches contain updates for your net-next tree,
they include:
* Little cleanup for IPVS the use of a strange notation to assign the
conntrack object, from Alan Cox.
* getsockopt support to obtain the original IPv6 address after NAT,
similar to the one that IPv4 provides, from Florian Westphal.
* Another little cleanup for nf_nat to save a couple of lines by using
PTR_RET, from Wu Fengguang.
You can pull these changes from:
git://1984.lsi.us.es/nf-next master
Thanks!
Alan Cox (1):
ipvs: remove silly double assignment
Florian Westphal (1):
netfilter: ipv6: add getsockopt to retrieve origdst
Wu Fengguang (1):
netfilter: nf_nat: use PTR_RET
include/uapi/linux/in6.h | 1 +
include/uapi/linux/netfilter_ipv6/ip6_tables.h | 3 ++
net/ipv4/netfilter/iptable_nat.c | 4 +-
net/ipv6/netfilter/ip6table_nat.c | 4 +-
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 61 ++++++++++++++++++++++++
net/netfilter/ipvs/ip_vs_nfct.c | 2 +-
net/netfilter/ipvs/ip_vs_xmit.c | 8 ++--
7 files changed, 72 insertions(+), 11 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 3/3] netfilter: ipv6: add getsockopt to retrieve origdst
From: pablo @ 2012-11-13 0:06 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1352765203-4160-1-git-send-email-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
userspace can query the original ipv4 destination address of a REDIRECTed
connection via
getsockopt(m_sock, SOL_IP, SO_ORIGINAL_DST, &m_server_addr, &addrsize)
but for ipv6 no such option existed.
This adds getsockopt(..., IPPROTO_IPV6, IP6T_SO_ORIGINAL_DST, ...).
Without this, userspace needs to parse /proc or use ctnetlink, which
appears to be overkill.
This uses option number 80 for IP6T_SO_ORIGINAL_DST, which is spare,
to use the same number we use in the IPv4 socket option SO_ORIGINAL_DST.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/in6.h | 1 +
include/uapi/linux/netfilter_ipv6/ip6_tables.h | 3 ++
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 61 ++++++++++++++++++++++++
3 files changed, 65 insertions(+)
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index 1e31599..f79c372 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -240,6 +240,7 @@ struct in6_flowlabel_req {
*
* IP6T_SO_GET_REVISION_MATCH 68
* IP6T_SO_GET_REVISION_TARGET 69
+ * IP6T_SO_ORIGINAL_DST 80
*/
/* RFC5014: Source address selection */
diff --git a/include/uapi/linux/netfilter_ipv6/ip6_tables.h b/include/uapi/linux/netfilter_ipv6/ip6_tables.h
index bf1ef65..649c680 100644
--- a/include/uapi/linux/netfilter_ipv6/ip6_tables.h
+++ b/include/uapi/linux/netfilter_ipv6/ip6_tables.h
@@ -178,6 +178,9 @@ struct ip6t_error {
#define IP6T_SO_GET_REVISION_TARGET (IP6T_BASE_CTL + 5)
#define IP6T_SO_GET_MAX IP6T_SO_GET_REVISION_TARGET
+/* obtain original address if REDIRECT'd connection */
+#define IP6T_SO_ORIGINAL_DST 80
+
/* ICMP matching stuff */
struct ip6t_icmp {
__u8 type; /* type to match */
diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
index 8860d23..02dcafd 100644
--- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
@@ -21,6 +21,7 @@
#include <linux/netfilter_bridge.h>
#include <linux/netfilter_ipv6.h>
+#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/netfilter/nf_conntrack.h>
#include <net/netfilter/nf_conntrack_helper.h>
#include <net/netfilter/nf_conntrack_l4proto.h>
@@ -295,6 +296,50 @@ static struct nf_hook_ops ipv6_conntrack_ops[] __read_mostly = {
},
};
+static int
+ipv6_getorigdst(struct sock *sk, int optval, void __user *user, int *len)
+{
+ const struct inet_sock *inet = inet_sk(sk);
+ const struct ipv6_pinfo *inet6 = inet6_sk(sk);
+ const struct nf_conntrack_tuple_hash *h;
+ struct sockaddr_in6 sin6;
+ struct nf_conntrack_tuple tuple = { .src.l3num = NFPROTO_IPV6 };
+ struct nf_conn *ct;
+
+ tuple.src.u3.in6 = inet6->rcv_saddr;
+ tuple.src.u.tcp.port = inet->inet_sport;
+ tuple.dst.u3.in6 = inet6->daddr;
+ tuple.dst.u.tcp.port = inet->inet_dport;
+ tuple.dst.protonum = sk->sk_protocol;
+
+ if (sk->sk_protocol != IPPROTO_TCP && sk->sk_protocol != IPPROTO_SCTP)
+ return -ENOPROTOOPT;
+
+ if (*len < 0 || (unsigned int) *len < sizeof(sin6))
+ return -EINVAL;
+
+ h = nf_conntrack_find_get(sock_net(sk), NF_CT_DEFAULT_ZONE, &tuple);
+ if (!h) {
+ pr_debug("IP6T_SO_ORIGINAL_DST: Can't find %pI6c/%u-%pI6c/%u.\n",
+ &tuple.src.u3.ip6, ntohs(tuple.src.u.tcp.port),
+ &tuple.dst.u3.ip6, ntohs(tuple.dst.u.tcp.port));
+ return -ENOENT;
+ }
+
+ ct = nf_ct_tuplehash_to_ctrack(h);
+
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_port = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u.tcp.port;
+ sin6.sin6_flowinfo = inet6->flow_label & IPV6_FLOWINFO_MASK;
+ memcpy(&sin6.sin6_addr,
+ &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.in6,
+ sizeof(sin6.sin6_addr));
+ sin6.sin6_scope_id = sk->sk_bound_dev_if;
+
+ nf_ct_put(ct);
+ return copy_to_user(user, &sin6, sizeof(sin6)) ? -EFAULT : 0;
+}
+
#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE)
#include <linux/netfilter/nfnetlink.h>
@@ -359,6 +404,14 @@ MODULE_ALIAS("nf_conntrack-" __stringify(AF_INET6));
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Yasuyuki KOZAKAI @USAGI <yasuyuki.kozakai@toshiba.co.jp>");
+static struct nf_sockopt_ops so_getorigdst6 = {
+ .pf = NFPROTO_IPV6,
+ .get_optmin = IP6T_SO_ORIGINAL_DST,
+ .get_optmax = IP6T_SO_ORIGINAL_DST + 1,
+ .get = ipv6_getorigdst,
+ .owner = THIS_MODULE,
+};
+
static int ipv6_net_init(struct net *net)
{
int ret = 0;
@@ -425,6 +478,12 @@ static int __init nf_conntrack_l3proto_ipv6_init(void)
need_conntrack();
nf_defrag_ipv6_enable();
+ ret = nf_register_sockopt(&so_getorigdst6);
+ if (ret < 0) {
+ pr_err("Unable to register netfilter socket option\n");
+ return ret;
+ }
+
ret = register_pernet_subsys(&ipv6_net_ops);
if (ret < 0)
goto cleanup_pernet;
@@ -440,6 +499,7 @@ static int __init nf_conntrack_l3proto_ipv6_init(void)
cleanup_ipv6:
unregister_pernet_subsys(&ipv6_net_ops);
cleanup_pernet:
+ nf_unregister_sockopt(&so_getorigdst6);
return ret;
}
@@ -448,6 +508,7 @@ static void __exit nf_conntrack_l3proto_ipv6_fini(void)
synchronize_net();
nf_unregister_hooks(ipv6_conntrack_ops, ARRAY_SIZE(ipv6_conntrack_ops));
unregister_pernet_subsys(&ipv6_net_ops);
+ nf_unregister_sockopt(&so_getorigdst6);
}
module_init(nf_conntrack_l3proto_ipv6_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] ipvs: remove silly double assignment
From: pablo @ 2012-11-13 0:06 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1352765203-4160-1-git-send-email-pablo@netfilter.org>
From: Alan Cox <alan@linux.intel.com>
I don't even want to think what the C spec says for this 8)
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_nfct.c | 2 +-
net/netfilter/ipvs/ip_vs_xmit.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_nfct.c b/net/netfilter/ipvs/ip_vs_nfct.c
index 022e77e..c8beafd 100644
--- a/net/netfilter/ipvs/ip_vs_nfct.c
+++ b/net/netfilter/ipvs/ip_vs_nfct.c
@@ -82,7 +82,7 @@ void
ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp, int outin)
{
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
struct nf_conntrack_tuple new_tuple;
if (ct == NULL || nf_ct_is_confirmed(ct) || nf_ct_is_untracked(ct) ||
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 12008b4..ee6b7a9 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -594,7 +594,7 @@ ip_vs_nat_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
if (cp->flags & IP_VS_CONN_F_SYNC && local) {
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ct && !nf_ct_is_untracked(ct)) {
IP_VS_DBG_RL_PKT(10, AF_INET, pp, skb, 0,
@@ -710,7 +710,7 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
if (cp->flags & IP_VS_CONN_F_SYNC && local) {
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ct && !nf_ct_is_untracked(ct)) {
IP_VS_DBG_RL_PKT(10, AF_INET6, pp, skb, 0,
@@ -1235,7 +1235,7 @@ ip_vs_icmp_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
if (cp->flags & IP_VS_CONN_F_SYNC && local) {
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ct && !nf_ct_is_untracked(ct)) {
IP_VS_DBG(10, "%s(): "
@@ -1356,7 +1356,7 @@ ip_vs_icmp_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
if (cp->flags & IP_VS_CONN_F_SYNC && local) {
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ct && !nf_ct_is_untracked(ct)) {
IP_VS_DBG(10, "%s(): "
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP replies originating via bridge
From: Jay Vosburgh @ 2012-11-12 23:40 UTC (permalink / raw)
To: Zheng Li; +Cc: netdev, andy, linux-kernel, davem, joe.jin
In-Reply-To: <1352714143-28160-1-git-send-email-zheng.x.li@oracle.com>
Zheng Li <zheng.x.li@oracle.com> wrote:
>ARP traffic passing through a bridge and out via the bond (when the bond is a
>port of the bridge) should not have its source MAC address adjusted by the
>receive load balance code in rlb_arp_xmit.
>
>Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
>Cc: Jay Vosburgh <fubar@us.ibm.com>
>Cc: Andy Gospodarek <andy@greyhouse.net>
>Cc: "David S. Miller" <davem@davemloft.net>
>
>---
> drivers/net/bonding/bond_alb.c | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>index e15cc11..a99e658 100644
>--- a/drivers/net/bonding/bond_alb.c
>+++ b/drivers/net/bonding/bond_alb.c
>@@ -685,6 +685,18 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
> return assigned_slave;
> }
>
>+struct slave *bond_slave_has_mac(struct bonding *bond, const u8 *mac)
>+{
>+ int i = 0;
>+ struct slave *tmp;
>+
>+ bond_for_each_slave(bond, tmp, i)
>+ if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
>+ return tmp;
>+
>+ return NULL;
>+}
This should go in bonding.h as a static line, so that other
parts of bonding can use it in the future. I'll also point out that
this function is one I suggested in a prior email, but did not test.
Presumably you've tested this.
> /* chooses (and returns) transmit channel for arp reply
> * does not choose channel for other arp types since they are
> * sent on the curr_active_slave
>@@ -700,7 +712,14 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
> */
> tx_slave = rlb_choose_channel(skb, bond);
> if (tx_slave) {
>- memcpy(arp->mac_src,tx_slave->dev->dev_addr, ETH_ALEN);
>+ struct slave *tmp_slave = NULL;
This does not need to be initialized, as the next line of code
assigns a value to it.
-J
>+ /* Only modify ARP's MAC if it originates locally;
>+ * don't change ARPs arriving via a bridge.
>+ */
>+ tmp_slave = bond_slave_has_mac(bond, arp->mac_src);
>+ if (tmp_slave)
>+ memcpy(arp->mac_src, tx_slave->dev->dev_addr,
>+ ETH_ALEN);
> }
> pr_debug("Server sent ARP Reply packet\n");
> } else if (arp->op_code == htons(ARPOP_REQUEST)) {
>--
>1.7.6.5
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH v3 2/9] net: rds: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-12 23:31 UTC (permalink / raw)
To: Shan Wei
Cc: venkat.x.venkatsubra, David Miller, rds-devel, NetDev,
Kernel-Maillist
In-Reply-To: <50A0EFE7.9010100@gmail.com>
On Mon, 12 Nov 2012, Shan Wei wrote:
> __percpu annotations in struct rds_ib_refill_cache is missing.
>
> you mean that read/write fields of struct rds_ib_cache_head
> using __this_cpu_* operation like following?
> How about it?
>
> diff --git a/net/rds/ib.h b/net/rds/ib.h
> index 8d2b3d5..7280ab8 100644
> --- a/net/rds/ib.h
> +++ b/net/rds/ib.h
> @@ -50,7 +50,7 @@ struct rds_ib_cache_head {
> };
>
> struct rds_ib_refill_cache {
> - struct rds_ib_cache_head *percpu;
> + struct rds_ib_cache_head __percpu *percpu;
That looks ok.
^ permalink raw reply
* Re: [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-12 23:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shan Wei, David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist
In-Reply-To: <1352492144.19779.811.camel@edumazet-glaptop>
On Fri, 9 Nov 2012, Eric Dumazet wrote:
> Its not the case.
>
> We need the _pointer_ to call :
>
> tasklet_schedule(tasklet);
Ah. Ok. In that case
Reviewed-by: Christoph Lameter <cl@linux.com>
^ permalink raw reply
* Re: [3.0.y, 3.2.y, 3.4.y] Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.
From: David Miller @ 2012-11-12 23:27 UTC (permalink / raw)
To: romieu
Cc: jrnieder, stable, kibi, netdev, nic_swsd, hayeswang, linux-kernel,
florent.fourcot
In-Reply-To: <20121112230339.GA28555@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 13 Nov 2012 00:03:39 +0100
> Jonathan Nieder <jrnieder@gmail.com> :
> [...]
>> This has been applied as commit b00e69dee4cc in mainline; thanks!
>>
>> Fran??ois and David, would this be a candidate for inclusion in
>> 3.0- and newer stable kernels?
>
> - 3.0.51
> b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
> aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
>
> - 3.4.18
> 0481776b7a70f09acf7d9d97c288c3a8403fbfe4
> b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
> aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
>
> - 3.6.6
> 0481776b7a70f09acf7d9d97c288c3a8403fbfe4
> b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
> aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
>
> I'll cook the patches.
Thank you, these all look fine for -stable to me.
^ permalink raw reply
* Re: [3.0.y, 3.2.y, 3.4.y] Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.
From: Francois Romieu @ 2012-11-12 23:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: davem, stable, Cyril Brulebois, netdev, nic_swsd, Hayes Wang,
linux-kernel, florent.fourcot
In-Reply-To: <20121112163858.GA4343@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> :
[...]
> This has been applied as commit b00e69dee4cc in mainline; thanks!
>
> Fran??ois and David, would this be a candidate for inclusion in
> 3.0- and newer stable kernels?
- 3.0.51
b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
- 3.4.18
0481776b7a70f09acf7d9d97c288c3a8403fbfe4
b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
- 3.6.6
0481776b7a70f09acf7d9d97c288c3a8403fbfe4
b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
I'll cook the patches.
--
Ueimor
^ permalink raw reply
* [PATCH] ipv4/ip_vti.c: VTI fix post-decryption forwarding
From: Saurabh @ 2012-11-12 22:17 UTC (permalink / raw)
To: netdev
With the latest kernel there are two things that must be done post decryption
so that the packet are forwarded.
1. Remove the mark from the packet. This will cause the packet to not match
the ipsec-policy again. However doing this causes the post-decryption check to
fail also and the packet will get dropped. (cat /proc/net/xfrm_stat).
2. Remove the sp association in the skbuff so that no policy check is done on
the packet for VTI tunnels.
Due to #2 above we must now do a security-policy check in the vti rcv path
prior to resetting the mark in the skbuff.
Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Reported-by: Ruben Herold <ruben@puettmann.net>
---
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 1831092..858fddf 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -338,12 +338,17 @@ static int vti_rcv(struct sk_buff *skb)
if (tunnel != NULL) {
struct pcpu_tstats *tstats;
+ if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
+ return -1;
+
tstats = this_cpu_ptr(tunnel->dev->tstats);
u64_stats_update_begin(&tstats->syncp);
tstats->rx_packets++;
tstats->rx_bytes += skb->len;
u64_stats_update_end(&tstats->syncp);
+ skb->mark = 0;
+ secpath_reset(skb);
skb->dev = tunnel->dev;
return 1;
}
^ permalink raw reply related
* Re: ath9k_htc-based adapter unfunctioning after commit ceb26a6013
From: Corey Richardson @ 2012-11-12 21:49 UTC (permalink / raw)
To: Adrian Chadd
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
jouni-A+ZNKFmMK5xy9aJCnZT0Uw, vthiagar-A+ZNKFmMK5xy9aJCnZT0Uw,
linville-2XuSBdqkA4R54TAoqtyWWQ,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, netdev-u79uwXL29TY76Z2rM5mHXA,
nbd-p3rKhJxN3npAfugRpC6u6w
In-Reply-To: <CAJ-Vmon04wLvn0DDnD9X98bY8DxHRQf10jQJCbuckbztS261vQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 12, 2012 at 4:39 PM, Adrian Chadd <adrian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote:
> Hi!
>
> Please create a bugzilla.kernel.org ticket with this info?
>
https://bugzilla.kernel.org/show_bug.cgi?id=50441
--
Corey Richardson
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: ath9k_htc-based adapter unfunctioning after commit ceb26a6013
From: Adrian Chadd @ 2012-11-12 21:39 UTC (permalink / raw)
To: Corey Richardson
Cc: linux-wireless, jouni, vthiagar, linville, ath9k-devel, netdev,
nbd
In-Reply-To: <CA++BO6SuRgOu7A4BKobrdEeSpSc3UUYHXaECmEGE=R17w7HjQA@mail.gmail.com>
Hi!
Please create a bugzilla.kernel.org ticket with this info?
Thanks,
adrian
On 12 November 2012 05:34, Corey Richardson <corey@octayn.net> wrote:
> I was giving 3.7-rc4 a whirl when I discovered my wireless adapter [0] wasn't
> working: the LED didn't light up. Went and ran 'ip link' and it just hung there.
> Tried a few other things and discovered that sudo was broken too. With
> strace I found that they were hanging in sendto().
>
> If I then unplug the adapter, everything comes out of the hang.
>
> Bisected and found that commit ceb26a6013b962b82f644189ea29d802490fc8fc is
> to blame.
>
> Attached is my .config,. The complete dmesg is attached, as well as
> dmesg_disconnect which is what gets spat out on disconnect of the device.
> strace is an strace of 'ip link'.
>
> I feel like I haven't given enough information; anything else needed?
>
> (Please CC me in any reply to a list; I am not subscribed to them)
>
> [0] - http://support.netgear.com/product/WNA1100
>
> --
> Corey Richardson
^ permalink raw reply
* [RFC net-next] tun: implement BQL
From: Stephen Hemminger @ 2012-11-12 21:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Add multiqueue BQL to tap device. Tested with VPN, doesn't have a big impact,
most likely because there is little queueing occuring at TAP device except
under case of forwarding.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/tun.c 2012-11-12 07:58:45.527037947 -0800
+++ b/drivers/net/tun.c 2012-11-12 11:20:26.017512742 -0800
@@ -412,6 +412,7 @@ static void __tun_detach(struct tun_file
tun_flow_delete_by_queue(tun, tun->numqueues + 1);
/* Drop read queue */
skb_queue_purge(&tfile->sk.sk_receive_queue);
+ netdev_tx_reset_queue(netdev_get_tx_queue(dev, index));
tun_set_real_num_queues(tun);
if (tun->numqueues == 0 && !(tun->flags & TUN_PERSIST))
@@ -455,6 +456,7 @@ static void tun_detach_all(struct net_de
lockdep_rtnl_is_held());
/* Drop read queue */
skb_queue_purge(&tfile->sk.sk_receive_queue);
+ netdev_tx_reset_queue(netdev_get_tx_queue(dev, i));
sock_put(&tfile->sk);
}
}
@@ -712,6 +714,8 @@ static netdev_tx_t tun_net_xmit(struct s
* for indefinite time. */
if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
goto drop;
+
+ netdev_tx_sent_queue(netdev_get_tx_queue(dev, txq), skb->len);
skb_orphan(skb);
/* Enqueue packet */
@@ -1324,6 +1328,10 @@ static ssize_t tun_do_read(struct tun_st
netif_wake_subqueue(tun->dev, tfile->queue_index);
ret = tun_put_user(tun, tfile, skb, iv, len);
+
+ netdev_tx_completed_queue(netdev_get_tx_queue(tun->dev,
+ tfile->queue_index),
+ 1, skb->len);
kfree_skb(skb);
break;
}
^ permalink raw reply
* [REGRESSION,v3.7-rc5,bisected] 100% CPU usage in softirqd, unable to shutdown
From: Lekensteyn @ 2012-11-12 21:20 UTC (permalink / raw)
To: Xiaotian Feng, David S. Miller; +Cc: netdev
Hi,
After upgrading from 3.7-rc4 to 3.7-rc5 I found that I was unable to suspend
without locking up the system afterwards. Neither was I able to shutdown as it
would simply hang where it should halt. The second suspend/resume in a session
would make Networkmanager hang.
When looking in my process list, I saw that softirqd was using one full CPU
core. Watching the contents of /proc/softirqs showed that the tasklet number
would rapidly increase.
I got this message when trying to suspend for the second time in a session:
Freezing user space processes ...
Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze,
wq_busy=0):
NetworkManager R running task 0 332 1 0x00000004
ffff88023169d628 ffffffff81549b86 ffff8802316e4470 ffff88023169dfd8
ffff88023169dfd8 ffff88023169dfd8 ffff8802316e4470 ffff8802316e4470
ffff88023169d698 ffff88023bc92a80 ffff88022fd3db70 ffff88022fd3dc90
Call Trace:
[<ffffffff81549b9e>] ? __schedule+0x13e/0x760
[<ffffffff8154a4f9>] schedule+0x29/0x70
[<ffffffff810722aa>] sys_sched_yield+0x4a/0x60
[<ffffffff8154a7c2>] yield+0x32/0x40
[<ffffffff810451f5>] tasklet_kill+0x35/0x80
[<ffffffffa017c2f3>] jme_close+0xd3/0x850 [jme]
[<ffffffff8146325d>] __dev_close_many+0x7d/0xc0
[<ffffffff814632cd>] __dev_close+0x2d/0x40
[<ffffffff81469551>] __dev_change_flags+0xa1/0x180
[<ffffffff814696e8>] dev_change_flags+0x28/0x70
[<ffffffff81475b68>] do_setlink+0x378/0xa00
[<ffffffff81078a56>] ? find_busiest_group+0x36/0x490
[<ffffffff812d5821>] ? nla_parse+0x31/0xe0
[<ffffffff812d5821>] ? nla_parse+0x31/0xe0
[<ffffffff81477e6e>] rtnl_newlink+0x36e/0x590
[<ffffffff81286e16>] ? apparmor_capable+0x26/0x90
[<ffffffff81477694>] rtnetlink_rcv_msg+0x114/0x300
[<ffffffff8114d1c3>] ? __kmalloc_node_track_caller+0x63/0x1b0
[<ffffffff8145b65b>] ? __alloc_skb+0x8b/0x290
[<ffffffff81477580>] ? __rtnl_unlock+0x20/0x20
[<ffffffff8148f471>] netlink_rcv_skb+0xb1/0xc0
[<ffffffff814748f5>] rtnetlink_rcv+0x25/0x40
[<ffffffff8148ed8b>] netlink_unicast+0x19b/0x220
[<ffffffff8148f111>] netlink_sendmsg+0x301/0x3c0
[<ffffffff8144f8ec>] sock_sendmsg+0xbc/0xf0
[<ffffffff81450797>] ? sock_recvmsg+0xd7/0x110
[<ffffffff8145045c>] __sys_sendmsg+0x3ac/0x3c0
[<ffffffff810854dc>] ? ktime_get_ts+0x4c/0xf0
[<ffffffff81452699>] sys_sendmsg+0x49/0x90
[<ffffffff81553906>] system_call_fastpath+0x1a/0x1f
Bisecting leads to:
commit 175c0dffef310fc7d7f026ca4a7682beb2fbd8ec
Author: Xiaotian Feng <xtfeng@gmail.com>
Date: Wed Oct 31 00:29:57 2012 +0000
drivers/net: use tasklet_kill in device remove/close process
Some driver uses tasklet_disable in device remove/close process,
tasklet_disable will inc tasklet->count and return. If the tasklet
is not handled yet because some softirq pressure, the tasklet will
placed on the tasklet_vec, never have a chance to excute. This might
lead to ksoftirqd heavy loaded, wakeup with pending_softirq, but
tasklet is disabled. tasklet_kill should be used in this case.
Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
(if it wasn't obvious, I have an Ethernet device that needs the "jme" driver,
04:00.5 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI
Express Gigabit Ethernet Controller [197b:0250] (rev 03))
Since 3.7, I sometimes get the below messages during suspend, but it would
never hang:
smpboot: CPU 2 is now offline
NOHZ: local_softirq_pending 02
NOHZ: local_softirq_pending 202
NOHZ: local_softirq_pending 202
NOHZ: local_softirq_pending 02
NOHZ: local_softirq_pending 202
NOHZ: local_softirq_pending 202
smpboot: CPU 3 is now offline
Time for a revert or do you have an other proposed fix?
Regards,
Peter
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc-based adapter unfunctioning after commit ceb26a6013
From: Andreas Philipp @ 2012-11-12 21:03 UTC (permalink / raw)
To: Corey Richardson
Cc: linux-wireless, vthiagar, netdev, jouni, linville, ath9k-devel
In-Reply-To: <CA++BO6SuRgOu7A4BKobrdEeSpSc3UUYHXaECmEGE=R17w7HjQA@mail.gmail.com>
Hello,
I am experiencing exactly the same problem. I will try to revert the
commit in question tomorrow and report the result.
Thanks,
Andreas Philipp
On 11/12/2012 02:34 PM, Corey Richardson wrote:
> I was giving 3.7-rc4 a whirl when I discovered my wireless adapter [0] wasn't
> working: the LED didn't light up. Went and ran 'ip link' and it just hung there.
> Tried a few other things and discovered that sudo was broken too. With
> strace I found that they were hanging in sendto().
>
> If I then unplug the adapter, everything comes out of the hang.
>
> Bisected and found that commit ceb26a6013b962b82f644189ea29d802490fc8fc is
> to blame.
>
> Attached is my .config,. The complete dmesg is attached, as well as
> dmesg_disconnect which is what gets spat out on disconnect of the device.
> strace is an strace of 'ip link'.
>
> I feel like I haven't given enough information; anything else needed?
>
> (Please CC me in any reply to a list; I am not subscribed to them)
>
> [0] - http://support.netgear.com/product/WNA1100
>
> --
> Corey Richardson
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: Build regressions/improvements in v3.7-rc5
From: Geert Uytterhoeven @ 2012-11-12 21:02 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, ceph-devel, netdev
In-Reply-To: <1352753886-3402-1-git-send-email-geert@linux-m68k.org>
On Mon, Nov 12, 2012 at 9:58 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.7-rc5 to v3.7-rc4[3], the summaries are:
> - build errors: +14/-4
14 regressions:
+ drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
use in this function): => 799:93
+ error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: => N/A
+ net/ceph/ceph_common.c: error: dereferencing pointer to incomplete
type: => 272:13
+ net/ceph/ceph_common.c: error: implicit declaration of function
'request_key' [-Werror=implicit-function-declaration]: => 249:2
+ net/ceph/crypto.c: error: dereferencing pointer to incomplete
type: => 463:19, 434:46, 452:5, 448:52, 429:23, 467:36, 447:18
+ net/ceph/crypto.c: error: implicit declaration of function
'key_payload_reserve' [-Werror=implicit-function-declaration]: =>
437:2
+ net/ceph/crypto.c: error: implicit declaration of function
'register_key_type' [-Werror=implicit-function-declaration]: => 481:2
+ net/ceph/crypto.c: error: implicit declaration of function
'unregister_key_type' [-Werror=implicit-function-declaration]: =>
485:2
+ net/ceph/crypto.c: error: unknown field 'destroy' specified in
initializer: => 477:2
+ net/ceph/crypto.c: error: unknown field 'instantiate' specified in
initializer: => 475:2
+ net/ceph/crypto.c: error: unknown field 'match' specified in
initializer: => 476:2
+ net/ceph/crypto.c: error: unknown field 'name' specified in
initializer: => 474:2
+ net/ceph/crypto.c: error: variable 'key_type_ceph' has initializer
but incomplete type: => 473:8
powerpc-randconfig
+ error: relocation truncated to fit: R_PPC64_REL24 against symbol
`._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o:
(.text+0x1ff9eb8) => (.text+0x1ffa274), (.text+0x1ff7840)
powerpc-allyesconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/5614/ (all 117 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/5600/ (all 117 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] vlan: Make it possible to add vlan with id 4095
From: Jan Engelhardt @ 2012-11-12 20:37 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, paulius.zaleckas, kaber, netdev
In-Reply-To: <50A14781.1030106@candelatech.com>
On Monday 2012-11-12 20:01, Ben Greear wrote:
>>>
>>> Awesome, we don't need VXVLAN any more after this fix.
>>
>> You mean because the special 0xfff value could indicate "here's more
>> headers"? Sounds like a plan.
>
> You can't just use reserved values...
Indeed not; I was just implicitly thinking of the 802.1Q standard
comittee getting an impetus from the public disgust against VXVLAN to
define 0xfff with extensions that allow for e.g. stacking, making
VXVLAN redundant and obsolete. :)
^ permalink raw reply
* net, batman: lockdep circular dependency warning
From: Sasha Levin @ 2012-11-12 20:37 UTC (permalink / raw)
To: Marek Lindner, Simon Wunderlich, Antonio Quartulli,
David S. Miller
Cc: b.a.t.m.a.n, netdev, linux-kernel@vger.kernel.org, Dave Jones
Hi all,
While fuzzing with trinity inside a KVM tools (lkvm) guest running latest -next
kernel, I've stumbled on the following:
[ 1002.969392] ======================================================
[ 1002.971639] [ INFO: possible circular locking dependency detected ]
[ 1002.975805] 3.7.0-rc5-next-20121112-sasha-00018-g2f4ce0e #127 Tainted: G W
[ 1002.983691] -------------------------------------------------------
[ 1002.983691] trinity-child18/8149 is trying to acquire lock:
[ 1002.983691] (s_active#313){++++.+}, at: [<ffffffff812f9941>] sysfs_addrm_finish+0x31/0x60
[ 1002.983691]
[ 1002.983691] but task is already holding lock:
[ 1002.983691] (rtnl_mutex){+.+.+.}, at: [<ffffffff834fcc62>] rtnl_lock+0x12/0x20
[ 1002.983691]
[ 1002.983691] which lock already depends on the new lock.
[ 1002.983691]
[ 1002.983691]
[ 1002.983691] the existing dependency chain (in reverse order) is:
[ 1002.983691]
-> #1 (rtnl_mutex){+.+.+.}:
[ 1002.983691] [<ffffffff81180d0a>] check_prevs_add+0xba/0x1a0
[ 1002.983691] [<ffffffff81181490>] validate_chain.isra.23+0x6a0/0x7b0
[ 1002.983691] [<ffffffff81183e3b>] __lock_acquire+0x9db/0xa90
[ 1002.983691] [<ffffffff8118635a>] lock_acquire+0x1ca/0x270
[ 1002.983691] [<ffffffff83bf647a>] __mutex_lock_common+0x5a/0x550
[ 1002.983691] [<ffffffff83bf69af>] mutex_lock_nested+0x3f/0x50
[ 1002.983691] [<ffffffff834fcc62>] rtnl_lock+0x12/0x20
[ 1002.983691] [<ffffffff834eeb3c>] netdev_run_todo+0x7c/0x180
[ 1002.983691] [<ffffffff834fcfa9>] rtnl_unlock+0x9/0x10
[ 1002.983691] [<ffffffff839d7da1>] batadv_store_mesh_iface+0x121/0x160
[ 1002.983691] [<ffffffff819d303f>] kobj_attr_store+0xf/0x30
[ 1002.983691] [<ffffffff812f7d41>] sysfs_write_file+0x101/0x170
[ 1002.983691] [<ffffffff8127ac58>] vfs_write+0xb8/0x180
[ 1002.983691] [<ffffffff8127af57>] sys_pwrite64+0x67/0x90
[ 1002.983691] [<ffffffff83bfafd8>] tracesys+0xe1/0xe6
[ 1002.983691]
-> #0 (s_active#313){++++.+}:
[ 1002.983691] [<ffffffff81180725>] check_prev_add+0x115/0x640
[ 1002.983691] [<ffffffff81180d0a>] check_prevs_add+0xba/0x1a0
[ 1002.983691] [<ffffffff81181490>] validate_chain.isra.23+0x6a0/0x7b0
[ 1002.983691] [<ffffffff81183e3b>] __lock_acquire+0x9db/0xa90
[ 1002.983691] [<ffffffff8118635a>] lock_acquire+0x1ca/0x270
[ 1002.983691] [<ffffffff812f8eaa>] sysfs_deactivate+0x11a/0x190
[ 1002.983691] [<ffffffff812f9941>] sysfs_addrm_finish+0x31/0x60
[ 1002.983691] [<ffffffff812f9a0a>] __sysfs_remove_dir+0x9a/0xd0
[ 1002.983691] [<ffffffff812f9f2f>] sysfs_remove_dir+0x3f/0x50
[ 1002.983691] [<ffffffff819d3806>] kobject_del+0x16/0x40
[ 1002.983691] [<ffffffff819d3930>] kobject_cleanup+0x100/0x190
[ 1002.983691] [<ffffffff819d39cd>] kobject_release+0xd/0x10
[ 1002.983691] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
[ 1002.983691] [<ffffffff839d8134>] batadv_sysfs_del_hardif+0x14/0x30
[ 1002.983691] [<ffffffff839cdacd>] batadv_hardif_remove_interface+0x5d/0x90
[ 1002.983691] [<ffffffff839cdba1>] batadv_hard_if_event+0xa1/0x2f0
[ 1002.983691] [<ffffffff8114271e>] notifier_call_chain+0xee/0x130
[ 1002.983691] [<ffffffff81142d31>] raw_notifier_call_chain+0x11/0x20
[ 1002.983691] [<ffffffff834e8dc2>] call_netdevice_notifiers+0x52/0x60
[ 1002.983691] [<ffffffff834ef4cd>] rollback_registered_many+0x14d/0x210
[ 1002.983691] [<ffffffff834ef5bc>] rollback_registered+0x2c/0x40
[ 1002.983691] [<ffffffff834ef650>] unregister_netdevice_queue+0x70/0xa0
[ 1002.983691] [<ffffffff834ef7bb>] unregister_netdev+0x1b/0x30
[ 1002.983691] [<ffffffff82a51fcc>] usbnet_disconnect+0x8c/0xf0
[ 1002.983691] [<ffffffff82b0aca7>] usb_unbind_interface+0x67/0x160
[ 1002.983691] [<ffffffff81e580a1>] __device_release_driver+0x81/0xe0
[ 1002.983691] [<ffffffff81e581f9>] device_release_driver+0x29/0x40
[ 1002.983691] [<ffffffff81e56c98>] bus_remove_device+0x138/0x150
[ 1002.983691] [<ffffffff81e54e8d>] device_del+0x13d/0x1a0
[ 1002.983691] [<ffffffff82b08459>] usb_disable_device+0xd9/0x270
[ 1002.983691] [<ffffffff82b08f38>] usb_set_configuration+0x268/0x7b0
[ 1002.983691] [<ffffffff82b0e5e3>] usb_remove_store+0x43/0x80
[ 1002.983691] [<ffffffff81e536c3>] dev_attr_store+0x13/0x30
[ 1002.983691] [<ffffffff812f7d41>] sysfs_write_file+0x101/0x170
[ 1002.983691] [<ffffffff8127ac58>] vfs_write+0xb8/0x180
[ 1002.983691] [<ffffffff8127ae10>] sys_write+0x50/0xa0
[ 1002.983691] [<ffffffff83bfafd8>] tracesys+0xe1/0xe6
[ 1002.983691]
[ 1002.983691] other info that might help us debug this:
[ 1002.983691]
[ 1002.983691] Possible unsafe locking scenario:
[ 1002.983691]
[ 1002.983691] CPU0 CPU1
[ 1002.983691] ---- ----
[ 1002.983691] lock(rtnl_mutex);
[ 1002.983691] lock(s_active#313);
[ 1002.983691] lock(rtnl_mutex);
[ 1002.983691] lock(s_active#313);
[ 1002.983691]
[ 1002.983691] *** DEADLOCK ***
[ 1002.983691]
[ 1002.983691] 4 locks held by trinity-child18/8149:
[ 1002.983691] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff812f7c7f>] sysfs_write_file+0x3f/0x170
[ 1002.983691] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff82b0e5c8>] usb_remove_store+0x28/0x80
[ 1002.983691] #2: (&__lockdep_no_validate__){......}, at: [<ffffffff81e581f1>] device_release_driver+0x21/0x40
[ 1002.983691] #3: (rtnl_mutex){+.+.+.}, at: [<ffffffff834fcc62>] rtnl_lock+0x12/0x20
[ 1002.983691]
[ 1002.983691] stack backtrace:
[ 1002.983691] Pid: 8149, comm: trinity-child18 Tainted: G W 3.7.0-rc5-next-20121112-sasha-00018-g2f4ce0e #127
[ 1002.983691] Call Trace:
[ 1002.983691] [<ffffffff83b322b9>] print_circular_bug+0xd3/0xe4
[ 1002.983691] [<ffffffff81180725>] check_prev_add+0x115/0x640
[ 1002.983691] [<ffffffff81180d0a>] check_prevs_add+0xba/0x1a0
[ 1002.983691] [<ffffffff8117e134>] ? graph_unlock+0xa4/0xb0
[ 1002.983691] [<ffffffff81181490>] validate_chain.isra.23+0x6a0/0x7b0
[ 1002.983691] [<ffffffff81183e3b>] __lock_acquire+0x9db/0xa90
[ 1002.983691] [<ffffffff81181ce9>] ? mark_held_locks+0xf9/0x130
[ 1002.983691] [<ffffffff811844af>] ? lockdep_init_map+0xcf/0x5e0
[ 1002.983691] [<ffffffff8118635a>] lock_acquire+0x1ca/0x270
[ 1002.983691] [<ffffffff812f9941>] ? sysfs_addrm_finish+0x31/0x60
[ 1002.983691] [<ffffffff812f8eaa>] sysfs_deactivate+0x11a/0x190
[ 1002.983691] [<ffffffff812f9941>] ? sysfs_addrm_finish+0x31/0x60
[ 1002.983691] [<ffffffff812f9941>] sysfs_addrm_finish+0x31/0x60
[ 1002.983691] [<ffffffff812f9a0a>] __sysfs_remove_dir+0x9a/0xd0
[ 1002.983691] [<ffffffff812f9f2f>] sysfs_remove_dir+0x3f/0x50
[ 1002.983691] [<ffffffff819d3806>] kobject_del+0x16/0x40
[ 1002.983691] [<ffffffff819d3930>] kobject_cleanup+0x100/0x190
[ 1002.983691] [<ffffffff819d39cd>] kobject_release+0xd/0x10
[ 1002.983691] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
[ 1002.983691] [<ffffffff839d8134>] batadv_sysfs_del_hardif+0x14/0x30
[ 1002.983691] [<ffffffff839cd040>] ? batadv_primary_if_update_addr+0x280/0x280
[ 1002.983691] [<ffffffff839cdacd>] batadv_hardif_remove_interface+0x5d/0x90
[ 1002.983691] [<ffffffff839cdba1>] batadv_hard_if_event+0xa1/0x2f0
[ 1002.983691] [<ffffffff8114271e>] notifier_call_chain+0xee/0x130
[ 1002.983691] [<ffffffff81142d31>] raw_notifier_call_chain+0x11/0x20
[ 1002.983691] [<ffffffff834e8dc2>] call_netdevice_notifiers+0x52/0x60
[ 1002.983691] [<ffffffff834ef4cd>] rollback_registered_many+0x14d/0x210
[ 1002.983691] [<ffffffff834ef5bc>] rollback_registered+0x2c/0x40
[ 1002.983691] [<ffffffff834ef650>] unregister_netdevice_queue+0x70/0xa0
[ 1002.983691] [<ffffffff834ef7bb>] unregister_netdev+0x1b/0x30
[ 1002.983691] [<ffffffff82a51fcc>] usbnet_disconnect+0x8c/0xf0
[ 1002.983691] [<ffffffff82b0aca7>] usb_unbind_interface+0x67/0x160
[ 1002.983691] [<ffffffff81e580a1>] __device_release_driver+0x81/0xe0
[ 1002.983691] [<ffffffff81e581f9>] device_release_driver+0x29/0x40
[ 1002.983691] [<ffffffff81e56c98>] bus_remove_device+0x138/0x150
[ 1002.983691] [<ffffffff81e54e8d>] device_del+0x13d/0x1a0
[ 1002.983691] [<ffffffff82b08459>] usb_disable_device+0xd9/0x270
[ 1002.983691] [<ffffffff82b08f38>] usb_set_configuration+0x268/0x7b0
[ 1002.983691] [<ffffffff82b0e5c8>] ? usb_remove_store+0x28/0x80
[ 1002.983691] [<ffffffff82b0e5e3>] usb_remove_store+0x43/0x80
[ 1002.983691] [<ffffffff81e536c3>] dev_attr_store+0x13/0x30
[ 1002.983691] [<ffffffff812f7d41>] sysfs_write_file+0x101/0x170
[ 1002.983691] [<ffffffff8127ac58>] vfs_write+0xb8/0x180
[ 1002.983691] [<ffffffff8127ae10>] sys_write+0x50/0xa0
[ 1002.983691] [<ffffffff83bfafd8>] tracesys+0xe1/0xe6
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net-next] ipv6 ndisc: Use pre-defined in6addr_linklocal_allnodes.
From: David Miller @ 2012-11-12 20:24 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <201211121750.qACHoHYE012220@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 13 Nov 2012 02:50:17 +0900
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/00] ipv4/ip_vti.c: VTI fix post-decryption forwarding
From: David Miller @ 2012-11-12 20:02 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
In-Reply-To: <20121112185214.GA26628@debian-saurabh-64.vyatta.com>
There is no such actual patch number "00/00". Please number your
patch properly and resubmit, thanks.
^ permalink raw reply
* Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Don Dutile @ 2012-11-12 19:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Jason Gao, Rose, Gregory V, Kirsher, Jeffrey T, linux-kernel,
netdev, kvm, e1000-devel@lists.sourceforge.net, linux-pci,
Yinghai Lu
In-Reply-To: <CAErSpo4xn9t=4yXGLdPQMtUJF=n38tYrMutAoj7NCsLUzQEbcg@mail.gmail.com>
On 11/09/2012 10:26 AM, Bjorn Helgaas wrote:
> [+ linux-pci, Yinghai]
>
> On Thu, Nov 8, 2012 at 8:59 PM, Jason Gao<pkill.2012@gmail.com> wrote:
>>> The BIOS in your machine doesn't support SR-IOV. You'll need to ask the manufacturer for a BIOS upgrade, if in fact one is available. Sometimes they're not.
>>
>> very thanks Greg,my server Dell R710 with latest BIOS version and
>> option for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused
>> that Does R710 provide full support for SR-IOV, kernel or ixgbe
>> driver's bug? but I'm not sure where the problem lies,anyone has any
>> experience about this? .
>
> Linux normally uses the resource assignments done by the BIOS, but it
> is possible for the kernel to reassign those. We don't have good
> automatic support for that yet, but on a recent upstream kernel, you
> can try "pci=realloc". I doubt this option is in CentOS 6.3, though.
>
Try moving the device into a different slot.
You may be trying it in a non-ARI slot in the 710; that is a problem
in RHEL6 (needing to realloc bus &/or mem-space).
A non-ARI slot will want to use one bus number per VF.... which will
be problematic.
I know I've seen ixgbe's (& their vfs's) working on a dell 710;
but they may also be one of those systems that has a slot off the ich10
with no ARI support.
> If an upstream kernel with "pci=realloc" still doesn't work, please
> post the entire dmesg log.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* tc adding two filters with different protocols
From: Nieścierowicz Adam @ 2012-11-12 19:45 UTC (permalink / raw)
To: Netdev
Hello,
writes the qos where i want classify traffic for two protocol: ip and
pppoe. Example below
---
tc qdisc del root dev eth2
tc qdisc add dev eth2 root handle 1: htb
tc class add dev eth2 parent 1:0 classid 1:1 htb rate 500Mbit ceil
500Mbit
tc filter add dev eth2 parent 1:0 prio 5 protocol ip u32
tc filter add dev eth2 parent 1:0 prio 5 handle 9: protocol ip u32
divisor 256
tc filter add dev eth2 protocol ip parent 1:0 prio 5 u32 ht 800:: match
ip dst 172.16.0.0/22 hashkey mask 0x000000ff at 16 link 9:
tc filter add dev eth2 parent 1:0 prio 6 protocol ppp_ses u32
tc filter add dev eth2 parent 1:0 prio 6 handle 4a: protocol ppp_ses
u32 divisor 256
tc filter add dev eth2 protocol ppp_ses parent 1:0 prio 6 u32 ht 800::
match ip dst 31.41.209.0/24 at 24 hashkey mask 0x000000ff at 24 link 4a:
---
Unfortunately, when you add lines "tc filter add dev eth2 protocol
ppp_ses parent 1:0 prio 6 u32 ht 800:: match ip dst 31.41.209.0/24 at 24
hashkey mask 0x000000ff at 24 link 4a:" protocol change to ip
command "tc -s -d filter show dev eth2" shows
---
filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 9: ht divisor 256
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht
800 bkt 0 link 9: (rule hit 557082 success 0)
match ac100000/fffffc00 at 16 (success 267341 )
hash mask 000000ff at 16
filter parent 1: protocol ip pref 5 u32 fh 800::801 order 2049 key ht
800 bkt 0 link 4a: (rule hit 557039 success 0)
match 1f29d100/ffffff00 at 24 (success 0 )
hash mask 000000ff at 24
filter parent 1: protocol ppp_ses pref 6 u32
filter parent 1: protocol ppp_ses pref 6 u32 fh 4a: ht divisor 256
filter parent 1: protocol ppp_ses pref 6 u32 fh 801: ht divisor 1
---
if i change order and first protocol is ppp_ses the hashkey for ip
protocol is changed to ppp_ses.
Is this correct behavior and I do something wrong?
Thanks
Adam N.
^ permalink raw reply
* Re: net/smsc911x: problems after commit 3ac3546e [Always wait for the chip to be ready]
From: David Miller @ 2012-11-12 19:40 UTC (permalink / raw)
To: kamlakant.patel; +Cc: steve, linus.walleij, robert.marklund, netdev
In-Reply-To: <20121112100445.GA12511@patelk@broadcom.com>
From: "Kamlakant Patel" <kamlakant.patel@broadcom.com>
Date: Mon, 12 Nov 2012 15:34:46 +0530
> On Thu, Nov 08, 2012 at 01:57:54AM -0500, David Miller wrote:
>> From: "Kamlakant Patel" <kamlakant.patel@broadcom.com>
>> Date: Thu, 8 Nov 2012 12:16:28 +0530
>>
>> > smsc driver is disabled in our bootloader and it is not changing the
>> > state of the smsc registers at any stage, so it is not a bootloader
>> > issue.
>>
>> What puts that chip into a non-default byte swapping mode then?
>
> This is a property of the XLP GBU (IO bus flash like devices). A 32-bit
> read/write will be split into two 16-bit operations, and when the XLP is
> in big-endian mode, we get the lower 16-bit ends up in bits 31-16 and the
> upper 16-bit in bits 15-0.
>
> The code before commit 3ac3546e worked because the driver saw that the registers
> are word swapped (not byte swapped) and programmed the WORD_SWAP register
> first (before any other register operations).
Ok, fair enough. Someone can resubmit the patch, and I'll apply it,
but I still very much dislike this situation.
Please make sure there is a very verbose comment added to the code,
and a similarly verbose commit message for the patch explaining
exactly how the chip gets into this state and why we have to solve
the problem this way.
Thanks.
^ permalink raw reply
* Re: [PATCH] vlan: Make it possible to add vlan with id 4095
From: Ben Greear @ 2012-11-12 19:01 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: David Miller, paulius.zaleckas, kaber, netdev
In-Reply-To: <alpine.LNX.2.01.1211121941370.1611@nerf07.vanv.qr>
On 11/12/2012 10:42 AM, Jan Engelhardt wrote:
> On Friday 2012-09-28 19:44, David Miller wrote:
>
>> From: Paulius Zaleckas <paulius.zaleckas@gmail.com>
>> Date: Fri, 28 Sep 2012 15:32:58 +0300
>>
>>> vconfig help tells that vlan_id should be 0-4095, but fails
>>> with 4095.
>>>
>>> There is an off-by-one bug while evaluating vlan_id.
>>> Fix it by evaluating against count(4096), not mask(0x0fff = 4095).
>>>
>>> Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
>>
>> Awesome, we don't need VXVLAN any more after this fix.
>
> You mean because the special 0xfff value could indicate "here's more
> headers"? Sounds like a plan.
You can't just use reserved values...they are for the standards writers
in case they ever need to officially extend the 802.1q spec somehow.
If you use it for non-standard purposes, you can set up conflicts with
future standards.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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