* Re: [PATCH net-next v4 1/4] netns: add genl cmd to add and get peer netns ids
From: Eric W. Biederman @ 2014-10-30 18:35 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
cwang-xCSkyg8dI+0RB7SZvlqPiA, linux-api-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1414682728-4532-2-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> writes:
> With this patch, a user can define an id for a peer netns by providing a FD or a
> PID. These ids are local to netns (ie valid only into one netns).
Scratches head. Do you actually find value in using the pid instead of
a file descriptor?
Doing things by pid was an early attempt to make things work, and has
been a bit clutsy. If you don't find value in it I would recommend just
supporting getting/setting the network namespace by file descriptor.
Eric
> This will be useful for netlink messages when a x-netns interface is dumped.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
> ---
> MAINTAINERS | 1 +
> include/net/net_namespace.h | 5 ++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/netns.h | 38 +++++++++
> net/core/net_namespace.c | 195 ++++++++++++++++++++++++++++++++++++++++++++
> net/netlink/genetlink.c | 4 +
> 6 files changed, 244 insertions(+)
> create mode 100644 include/uapi/linux/netns.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43898b1a8a2d..de7e6fcbd5c2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6382,6 +6382,7 @@ F: include/linux/netdevice.h
> F: include/uapi/linux/in.h
> F: include/uapi/linux/net.h
> F: include/uapi/linux/netdevice.h
> +F: include/uapi/linux/netns.h
> F: tools/net/
> F: tools/testing/selftests/net/
> F: lib/random32.c
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index e0d64667a4b3..0f1367a71b81 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -59,6 +59,7 @@ struct net {
> struct list_head exit_list; /* Use only net_mutex */
>
> struct user_namespace *user_ns; /* Owning user namespace */
> + struct idr netns_ids;
>
> unsigned int proc_inum;
>
> @@ -289,6 +290,10 @@ static inline struct net *read_pnet(struct net * const *pnet)
> #define __net_initconst __initconst
> #endif
>
> +int peernet2id(struct net *net, struct net *peer);
> +struct net *get_net_ns_by_id(struct net *net, int id);
> +int netns_genl_register(void);
> +
> struct pernet_operations {
> struct list_head list;
> int (*init)(struct net *net);
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 6cad97485bad..d7f49c69585a 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -277,6 +277,7 @@ header-y += netfilter_decnet.h
> header-y += netfilter_ipv4.h
> header-y += netfilter_ipv6.h
> header-y += netlink.h
> +header-y += netns.h
> header-y += netrom.h
> header-y += nfc.h
> header-y += nfs.h
> diff --git a/include/uapi/linux/netns.h b/include/uapi/linux/netns.h
> new file mode 100644
> index 000000000000..2edf129377de
> --- /dev/null
> +++ b/include/uapi/linux/netns.h
> @@ -0,0 +1,38 @@
> +/* Copyright (c) 2014 6WIND S.A.
> + * Author: Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +#ifndef _UAPI_LINUX_NETNS_H_
> +#define _UAPI_LINUX_NETNS_H_
> +
> +/* Generic netlink messages */
> +
> +#define NETNS_GENL_NAME "netns"
> +#define NETNS_GENL_VERSION 0x1
> +
> +/* Commands */
> +enum {
> + NETNS_CMD_UNSPEC,
> + NETNS_CMD_NEWID,
> + NETNS_CMD_GETID,
> + __NETNS_CMD_MAX,
> +};
> +
> +#define NETNS_CMD_MAX (__NETNS_CMD_MAX - 1)
> +
> +/* Attributes */
> +enum {
> + NETNSA_NONE,
> +#define NETNSA_NSINDEX_UNKNOWN -1
> + NETNSA_NSID,
> + NETNSA_PID,
> + NETNSA_FD,
> + __NETNSA_MAX,
> +};
> +
> +#define NETNSA_MAX (__NETNSA_MAX - 1)
> +
> +#endif /* _UAPI_LINUX_NETNS_H_ */
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 7f155175bba8..4a5680ed42fb 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -15,6 +15,8 @@
> #include <linux/file.h>
> #include <linux/export.h>
> #include <linux/user_namespace.h>
> +#include <linux/netns.h>
> +#include <net/genetlink.h>
> #include <net/net_namespace.h>
> #include <net/netns/generic.h>
>
> @@ -144,6 +146,50 @@ static void ops_free_list(const struct pernet_operations *ops,
> }
> }
>
> +/* This function is used by idr_for_each(). If net is equal to peer, the
> + * function returns the id so that idr_for_each() stops. Because we cannot
> + * returns the id 0 (idr_for_each() will not stop), we return the magic value
> + * -1 for it.
> + */
> +static int net_eq_idr(int id, void *net, void *peer)
> +{
> + if (net_eq(net, peer))
> + return id ? : -1;
> + return 0;
> +}
> +
> +/* returns NETNSA_NSINDEX_UNKNOWN if not found */
> +int peernet2id(struct net *net, struct net *peer)
> +{
> + int id = idr_for_each(&net->netns_ids, net_eq_idr, peer);
> +
> + ASSERT_RTNL();
> +
> + /* Magic value for id 0. */
> + if (id == -1)
> + return 0;
> + if (id == 0)
> + return NETNSA_NSINDEX_UNKNOWN;
> +
> + return id;
> +}
> +
> +struct net *get_net_ns_by_id(struct net *net, int id)
> +{
> + struct net *peer;
> +
> + if (id < 0)
> + return NULL;
> +
> + rcu_read_lock();
> + peer = idr_find(&net->netns_ids, id);
> + if (peer)
> + get_net(peer);
> + rcu_read_unlock();
> +
> + return peer;
> +}
> +
> /*
> * setup_net runs the initializers for the network namespace object.
> */
> @@ -158,6 +204,7 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
> atomic_set(&net->passive, 1);
> net->dev_base_seq = 1;
> net->user_ns = user_ns;
> + idr_init(&net->netns_ids);
>
> #ifdef NETNS_REFCNT_DEBUG
> atomic_set(&net->use_count, 0);
> @@ -288,6 +335,14 @@ static void cleanup_net(struct work_struct *work)
> list_for_each_entry(net, &net_kill_list, cleanup_list) {
> list_del_rcu(&net->list);
> list_add_tail(&net->exit_list, &net_exit_list);
> + for_each_net(tmp) {
> + int id = peernet2id(tmp, net);
> +
> + if (id >= 0)
> + idr_remove(&tmp->netns_ids, id);
> + }
> + idr_destroy(&net->netns_ids);
> +
> }
> rtnl_unlock();
>
> @@ -399,6 +454,146 @@ static struct pernet_operations __net_initdata net_ns_ops = {
> .exit = net_ns_net_exit,
> };
>
> +static struct genl_family netns_genl_family = {
> + .id = GENL_ID_GENERATE,
> + .name = NETNS_GENL_NAME,
> + .version = NETNS_GENL_VERSION,
> + .hdrsize = 0,
> + .maxattr = NETNSA_MAX,
> + .netnsok = true,
> +};
> +
> +static struct nla_policy netns_nl_policy[NETNSA_MAX + 1] = {
> + [NETNSA_NONE] = { .type = NLA_UNSPEC },
> + [NETNSA_NSID] = { .type = NLA_S32 },
> + [NETNSA_PID] = { .type = NLA_U32 },
> + [NETNSA_FD] = { .type = NLA_U32 },
> +};
> +
> +static int netns_nl_cmd_newid(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct net *net = genl_info_net(info);
> + struct net *peer;
> + int nsid, err;
> +
> + if (!info->attrs[NETNSA_NSID])
> + return -EINVAL;
> + nsid = nla_get_s32(info->attrs[NETNSA_NSID]);
> + if (nsid < 0)
> + return -EINVAL;
> +
> + if (info->attrs[NETNSA_PID])
> + peer = get_net_ns_by_pid(nla_get_u32(info->attrs[NETNSA_PID]));
> + else if (info->attrs[NETNSA_FD])
> + peer = get_net_ns_by_fd(nla_get_u32(info->attrs[NETNSA_FD]));
> + else
> + return -EINVAL;
> + if (IS_ERR(peer))
> + return PTR_ERR(peer);
> +
> + rtnl_lock();
> + if (peernet2id(net, peer) >= 0) {
> + err = -EEXIST;
> + goto out;
> + }
> +
> + err = idr_alloc(&net->netns_ids, peer, nsid, nsid + 1, GFP_KERNEL);
> + if (err >= 0)
> + err = 0;
> +out:
> + rtnl_unlock();
> + put_net(peer);
> + return err;
> +}
> +
> +static int netns_nl_get_size(void)
> +{
> + return nla_total_size(sizeof(s32)) /* NETNSA_NSID */
> + ;
> +}
> +
> +static int netns_nl_fill(struct sk_buff *skb, u32 portid, u32 seq, int flags,
> + int cmd, struct net *net, struct net *peer)
> +{
> + void *hdr;
> + int id;
> +
> + hdr = genlmsg_put(skb, portid, seq, &netns_genl_family, flags, cmd);
> + if (!hdr)
> + return -EMSGSIZE;
> +
> + rtnl_lock();
> + id = peernet2id(net, peer);
> + rtnl_unlock();
> + if (nla_put_s32(skb, NETNSA_NSID, id))
> + goto nla_put_failure;
> +
> + return genlmsg_end(skb, hdr);
> +
> +nla_put_failure:
> + genlmsg_cancel(skb, hdr);
> + return -EMSGSIZE;
> +}
> +
> +static int netns_nl_cmd_getid(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct net *net = genl_info_net(info);
> + struct sk_buff *msg;
> + int err = -ENOBUFS;
> + struct net *peer;
> +
> + if (info->attrs[NETNSA_PID])
> + peer = get_net_ns_by_pid(nla_get_u32(info->attrs[NETNSA_PID]));
> + else if (info->attrs[NETNSA_FD])
> + peer = get_net_ns_by_fd(nla_get_u32(info->attrs[NETNSA_FD]));
> + else
> + return -EINVAL;
> +
> + if (IS_ERR(peer))
> + return PTR_ERR(peer);
> +
> + msg = genlmsg_new(netns_nl_get_size(), GFP_KERNEL);
> + if (!msg) {
> + err = -ENOMEM;
> + goto out;
> + }
> +
> + err = netns_nl_fill(msg, info->snd_portid, info->snd_seq,
> + NLM_F_ACK, NETNS_CMD_GETID, net, peer);
> + if (err < 0)
> + goto err_out;
> +
> + err = genlmsg_unicast(net, msg, info->snd_portid);
> + goto out;
> +
> +err_out:
> + nlmsg_free(msg);
> +out:
> + put_net(peer);
> + return err;
> +}
> +
> +static struct genl_ops netns_genl_ops[] = {
> + {
> + .cmd = NETNS_CMD_NEWID,
> + .policy = netns_nl_policy,
> + .doit = netns_nl_cmd_newid,
> + .flags = GENL_ADMIN_PERM,
> + },
> + {
> + .cmd = NETNS_CMD_GETID,
> + .policy = netns_nl_policy,
> + .doit = netns_nl_cmd_getid,
> + .flags = GENL_ADMIN_PERM,
> + },
> +};
> +
> +int netns_genl_register(void)
> +{
> + return genl_register_family_with_ops(&netns_genl_family,
> + netns_genl_ops);
> +}
> +
> static int __init net_ns_init(void)
> {
> struct net_generic *ng;
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 76393f2f4b22..c6f39e40c9f3 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -1029,6 +1029,10 @@ static int __init genl_init(void)
> if (err)
> goto problem;
>
> + err = netns_genl_register();
> + if (err < 0)
> + goto problem;
> +
> return 0;
>
> problem:
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] netns: allow to identify peer netns
From: Eric W. Biederman @ 2014-10-30 18:41 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
cwang-xCSkyg8dI+0RB7SZvlqPiA, linux-api-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1414682728-4532-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> writes:
> The goal of this serie is to be able to multicast netlink messages with an
> attribute that identify a peer netns.
> This is needed by the userland to interpret some informations contained in
> netlink messages (like IFLA_LINK value, but also some other attributes in case
> of x-netns netdevice (see also
> http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
> http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
>
> Ids of peer netns are set by userland via a new genl messages. These ids are
> stored per netns and are local (ie only valid in the netns where they are set).
> To avoid allocating an int for each peer netns, I use idr_for_each() to retrieve
> the id of a peer netns. Note that it will be possible to add a table (struct net
> -> id) later to optimize this lookup if needed.
>
> Patch 1/4 introduces the netlink API mechanism to set and get these ids.
> Patch 2/4 and 3/4 implements an example of how to use these ids in rtnetlink
> messages. And patch 4/4 shows that the netlink messages can be symetric between
> a GET and a SET.
>
> iproute2 patches are available, I can send them on demand.
A quick reply. I think this patchset is in the right general direction.
There are some oddball details that seem odd/awkward to me such as using
genetlink instead of rtnetlink to get and set the ids, and not having
ids if they are not set (that feels like a maintenance/usability challenge).
I would like to give your patches a deep review, but I won't be able to
do that for a couple of weeks. I am deep in the process of moving,
and will be mostly offline until about the Nov 11th.
Eric
> Here is a small screenshot to show how it can be used by userland.
>
> First, setup netns and required ids:
> $ ip netns add foo
> $ ip netns del foo
> $ ip netns
> $ touch /var/run/netns/init_net
> $ mount --bind /proc/1/ns/net /var/run/netns/init_net
> $ ip netns add foo
> $ ip netns exec foo ip netns set init_net 0
> $ ip netns
> foo
> init_net
> $ ip netns exec foo ip netns
> foo
> init_net (id: 0)
>
> Now, add and display an ipip tunnel, with its link part in init_net (id 0 in
> netns foo) and the netdevice in foo:
> $ ip netns exec foo ip link add ipip1 link-netnsid 0 type ipip remote 10.16.0.121 local 10.16.0.249
> $ ip netns exec foo ip l ls ipip1
> 6: ipip1@NONE: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
> link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 0
>
> The parameter link-netnsid shows us where the interface sends and receives
> packets (and thus we know where encapsulated addresses are set).
>
> RFCv3 -> v4:
> rebase on net-next
> add copyright text in the new netns.h file
>
> RFCv2 -> RFCv3:
> ids are now defined by userland (via netlink). Ids are stored in each netns
> (and they are local to this netns).
> add get_link_net support for ip6 tunnels
> netnsid is now a s32 instead of a u32
>
> RFCv1 -> RFCv2:
> remove useless ()
> ids are now stored in the user ns. It's possible to get an id for a peer netns
> only if the current netns and the peer netns have the same user ns parent.
>
> MAINTAINERS | 1 +
> include/net/ip6_tunnel.h | 1 +
> include/net/ip_tunnels.h | 1 +
> include/net/net_namespace.h | 5 ++
> include/net/rtnetlink.h | 2 +
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/if_link.h | 1 +
> include/uapi/linux/netns.h | 38 +++++++++
> net/core/net_namespace.c | 195 +++++++++++++++++++++++++++++++++++++++++++
> net/core/rtnetlink.c | 38 ++++++++-
> net/ipv4/ip_gre.c | 2 +
> net/ipv4/ip_tunnel.c | 8 ++
> net/ipv4/ip_vti.c | 1 +
> net/ipv4/ipip.c | 1 +
> net/ipv6/ip6_gre.c | 1 +
> net/ipv6/ip6_tunnel.c | 9 ++
> net/ipv6/ip6_vti.c | 1 +
> net/ipv6/sit.c | 1 +
> net/netlink/genetlink.c | 4 +
> 19 files changed, 308 insertions(+), 3 deletions(-)
>
> Comments are welcome.
>
> Regards,
> Nicolas
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Eric Dumazet @ 2014-10-30 18:47 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1414693632.16849.62.camel@decadent.org.uk>
On Thu, 2014-10-30 at 18:27 +0000, Ben Hutchings wrote:
> + {
> + static bool warned;
> +
> + if (!warned) {
> + warned = true;
> + netdev_warn(tun->dev,
> + "%s: using disabled UFO feature; please fix this program\n",
> + current->comm);
> + }
>
It might be time to add netdev_warn_once() ;)
Alternatively, you could use
pr_warn_once("%s: using disabled UFO feature; please fix this program\n",
tun->dev->name, current->comm);
^ permalink raw reply
* Re: [PATCH v3 00/15] net: dsa: Fixes and enhancements
From: David Miller @ 2014-10-30 18:54 UTC (permalink / raw)
To: linux; +Cc: f.fainelli, netdev, andrew, linux-kernel
In-Reply-To: <20141029213928.GA28498@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Wed, 29 Oct 2014 14:39:28 -0700
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
From: Eric Dumazet @ 2014-10-30 19:00 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev, Matan Barak, Amir Vadai, Saeed Mahameed,
Shani Michaeli
In-Reply-To: <1414685216-28907-6-git-send-email-ogerlitz@mellanox.com>
On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
> Remove the code which goes through napi_gro_frags() on the RX path,
> use only napi_gro_receive().
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
Hmpff... napi_gro_frags() should be faster.
Have you benchmarked this ?
^ permalink raw reply
* Re: nfs stalls over loopback interface (no sk_data_ready events?)
From: Christoph Hellwig @ 2014-10-30 19:00 UTC (permalink / raw)
To: Jeff Layton
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
Linux NFS Mailing List, Bruce Fields, Trond Myklebust
In-Reply-To: <20141029102123.58f6c960-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Wed, Oct 29, 2014 at 10:21:23AM -0400, Jeff Layton wrote:
> Looks some change that went into -rc2 has fixed the problem for me.
> Christoph, can you confirm that this no longer occurs with -rc2?
I can't reproduce it anymore on -rc2.
However:
generic/133 fails fairly reliably with:
Buffered writer, buffered reader
+pread64: Device or resource busy
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: Mistake in commit 0d961b3b52f566f823070ce2366511a7f64b928c breaks cpsw non dual_emac mode.
From: David Miller @ 2014-10-30 19:43 UTC (permalink / raw)
To: lsorense; +Cc: linux-kernel, hs, mugunthanvnm, netdev
In-Reply-To: <20141028170242.GA24112@csclub.uwaterloo.ca>
From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Date: Tue, 28 Oct 2014 13:02:42 -0400
> I believe commit 0d961b3b52f566f823070ce2366511a7f64b928c made a mistake
> while correcting a bug.
This patch submission is not properly formed.
You subject line should be of the form:
subsystem: Description.
"subsystem" here would be "cpsw: " or something like that.
Secondly, you should not refer to a commit ID in the patch
Subject line, instead just describe exactly what is being
fixed in the most succinct yet complete manner that is
possible.
Thirdly, when you do refer to commit ID's in your commit
message body you must do so in the following format:
${SHA1_ID} ("Commit message header line text.")
The commit message body is also not a place to have a general
discussion. Please avoid saying things like "I think", for example.
State facts, and be exact about what the problem is and exactly
how you are fixing it.
Because this commit message will be read by others looking at your
change days, weeks, years from now.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] reduce verifier memory consumption and add tests
From: David Miller @ 2014-10-30 19:45 UTC (permalink / raw)
To: ast; +Cc: hannes, edumazet, dborkman, luto, netdev, linux-kernel
In-Reply-To: <1414534303-9906-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Tue, 28 Oct 2014 15:11:40 -0700
> Small set of cleanups:
> - reduce verifier memory consumption
> - add verifier test to check register state propagation and state equivalence
> - add JIT test reduced from recent nmap triggered crash
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] r8152: patches for autosuspend
From: David Miller @ 2014-10-30 19:49 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-69-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 29 Oct 2014 11:12:14 +0800
> There are unexpected processes when enabling autosuspend.
> These patches are used to fix them.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
From: Arend van Spriel @ 2014-10-30 19:51 UTC (permalink / raw)
To: Larry Finger
Cc: Luca Coelho, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Murilo Opsfelder Araujo
In-Reply-To: <545258D6.20000-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 10/30/14 16:27, Larry Finger wrote:
> On 10/30/2014 06:08 AM, Luca Coelho wrote:
>> The cover-letter subject is wrong. :) I guess you meant
>> s/iwlwifi/rtlwifi/ ;)
>
> Yes, the changes were for rtlwifi, not iwlwifi. Sorry. (:
>
> My laptop has an Intel 7260 card built in, and it is working correctly
> on both 2.4 and 5G bands under mainline 3.18-rc2.
>
> Those types of errors are what I get for trying to "work" while on a
> family vacation. Unfortunately, I needed to submit those patches quickly
> to prevent a set of conflicting updates from being accepted, and I made
> a silly mistake.
Don't let it spoil your vacation ;-)
Regards,
Arend
> Larry
>
> --
> 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
--
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: [PATCH 1/1 net-next] ipx: remove all unnecessary castings on ntohl
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1414571502-9231-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 09:31:42 +0100
> Apply commit e0f36310f793
> ("ipx: remove unnecessary casting on ntohl")
> to all seq_printf/08lX
>
> Inspired-by: "David S. Miller" <davem@davemloft.net>
> Inspired-by: Joe Perches <joe@perches.com>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH/TRIVIAL 1/1 net-next] ipv6: spelling s/incomming/incoming
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, trivial, netdev
In-Reply-To: <1414573227-10743-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 10:00:26 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove inline on static in c file
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414579097-11659-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 11:38:17 +0100
> remove __inline__ / inline and let compiler decide what to do
> with static functions
>
> Inspired-by: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove assignment in if condition
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414583871-14196-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 12:57:51 +0100
> Do assignment before if condition and test !skb like in rawv6_recvmsg()
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: David Miller @ 2014-10-30 19:59 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20141029122307.GA29253@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 29 Oct 2014 13:23:07 +0100
> We could do that, if you prefer.
>
> I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> then we want to enable 'passive' ecn for incoming connections only on
> a particular route without announcing ecn to the peer. I haven't been
> able to find any -- I think if you deem 'route to x' safe for ecn it
> might as well be enabled for both initiator and responder. The original
> patch would be sufficient for that.
>
> IOW, is 'ecn from a to b but not b to a' a sensible requirement?
I think you have to apply the same logic for the sysctl (there's a
reason to only support ECN passively) as you do for the route feature
because you can logically look at the sysctl as applying to the
default route.
> Unrelated to this patch, but I'd like to see sysctl_tcp_ecn=1 as a
> default at one point (almost no routers set CE bit at this time, perhaps
> that would change if ecn usage is more widespread).
Now you're talking.
So, either passive ECN support makes sense or it does not. To me, no
matter what the argument, it doesn't matter what realm (whole system,
specific routes) you apply that argument to.
^ permalink raw reply
* Re: [PATCH v2] ip6_tunnel: allow to change mode for the ip6tnl0
From: David Miller @ 2014-10-30 20:09 UTC (permalink / raw)
To: alan; +Cc: netdev, edumazet
In-Reply-To: <1414569292-15384-1-git-send-email-alan@al-an.info>
From: "Alexey Andriyanov" <alan@al-an.info>
Date: Wed, 29 Oct 2014 10:54:52 +0300
> The fallback device is in ipv6 mode by default.
> The mode can not be changed in runtime, so there
> is no way to decapsulate ip4in6 packets coming from
> various sources without creating the specific tunnel
> ifaces for each peer.
>
> This allows to update the fallback tunnel device, but only
> the mode could be changed. Usual command should work for the
> fallback device: `ip -6 tun change ip6tnl0 mode any`
>
> The fallback device can not be hidden from the packet receiver
> as a regular tunnel, but there is no need for synchronization
> as long as we do single assignment.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Alexey Andriyanov <alan@al-an.info>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: David Miller @ 2014-10-30 20:11 UTC (permalink / raw)
To: logan; +Cc: netdev
In-Reply-To: <20141029172915.GA15714@mx.elandsys.com>
From: Loganaden Velvindron <logan@elandsys.com>
Date: Wed, 29 Oct 2014 10:29:15 -0700
> (It's my first time sending a diff to netdev, please let me know if
> I made a mistake)
Please don't put text like this into the commit log message body.
^ permalink raw reply
* Re: PATCH: Add IFF_ALLMULTI support to cpsw (and fix IFF_PROMISC support too)
From: David Miller @ 2014-10-30 20:12 UTC (permalink / raw)
To: lsorense; +Cc: linux-kernel, mugunthanvnm, netdev
In-Reply-To: <20141029190612.GH24110@csclub.uwaterloo.ca>
From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Date: Wed, 29 Oct 2014 15:06:12 -0400
> The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
> multicast routing rather hard to handle. Related to this, when enabling
> IFF_PROMISC in non dual_emac mode, all registered vlans are flushed,
> and only broadcast and unicast are allowed which isn't what you would
> want from IFF_PROMISC.
>
> A new cpsw_ale_set_allmulti function now scans through the ALE entry
> table and adds or removes the host port from the unregistered multicast
> port mask depending on the state of IFF_ALLMULTI. In promisc mode,
> it is also called to enable reception of all multicast traffic.
>
> With this change I am now able to run dynamic multicast routing and also
> use tcpdump and actually see multicast traffic.
>
> Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Please fix your Subject line and resubmit this patch.
Subject lines end up as the commit message header text, and
therefore must be of the form:
subsystem: Description.
In this case "cpsw: " is probably an appropriate subsystem
prefix.
^ permalink raw reply
* Re: [PATCH net-next] tcp: allow for bigger reordering level
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1414610869.631.94.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 12:27:49 -0700
> Yuchung and othres are working on a new way to handle reorders (RACK),
> and should present the concept in next IETF meeting.
>
> A linux patch should follow shortly.
>
> High level idea is :
>
> Decide when and what to retransmit based on the timing, instead of
> sequence, relationships. This covers both original or retransmitted
> packets.
>
> On dupacks, wait a fraction of RTT before the repair process to both
> allow reordering and relieve the network
My instint says that this delay will increase recovery time, but I
guess they've taken that into consideration :-)
^ permalink raw reply
* Re: [PATCH net-next] ipv4: minor spelling fixes
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20141029160506.46011813@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 29 Oct 2014 16:05:06 -0700
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-10-30 20:32 UTC (permalink / raw)
To: Denis Kirjanov
Cc: netdev@vger.kernel.org, linuxppc-dev, Michael Ellerman,
Matt Evans
In-Reply-To: <1414649535-3956-1-git-send-email-kda@linux-powerpc.org>
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> skb->pkt_type field.
>
> Before:
> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>
> After:
> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
if you'd only quoted #12, it would all make sense ;)
but #11 test is not using PKTTYPE. So your patch shouldn't
make a difference. Are these numbers with JIT on and off?
^ permalink raw reply
* Re: [PATCH 6/7] can: m_can: update to support CAN FD features
From: Oliver Hartkopp @ 2014-10-30 20:32 UTC (permalink / raw)
To: Dong Aisheng; +Cc: linux-can, mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <20141030024226.GA29572@shlinux1.ap.freescale.net>
On 10/30/2014 03:42 AM, Dong Aisheng wrote:
> On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
>> So first I would suggest to check the core release register (CREL) to be
>> version 3.0.x and quit the driver initialization if it doesn't fit this
>> version. I would suggest to provide a separate patch for that check. What
>> about printing the core release version into the kernel log at driver
>> initialization time?
>>
>
> One question is that if v3.1.0 and v3.2.0 will be backward compatible with
> v3.0.1, if yes, how about let the driver still work for them instead of
> simply quit?
There are several important differences between 3.0.x and 3.1.x.
E.g. the CCCR, BTP, PSR and others are changed and a register for the
transmitter delay compensation is added.
I assume from 3.1.x to 3.2.x the controller registers will only change in
small details as the main update will be on the wire and not in the functionality.
> And then we can add new features according new released IP version.
Yes. We probably can wait for 3.[12].x to become available before adding the
special code that behaves according the core release register content.
>>> @@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
>>> if (rxfs & RXFS_RFL)
>>> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
>>>
>>> - skb = alloc_can_skb(dev, &frame);
>>> + skb = alloc_canfd_skb(dev, &frame);
>>
>> You are *always* allocating CAN FD frames now?
>>
>
> Yes, currently it is.
> The test seemed ok using CAN FD frames even receive normal frame.
When you put CAN frame content into a CAN FD skb it becomes a CAN FD frame -
which is wrong.
CAN 2.0 frame (EDL is clear) -> alloc_can_skb()
CAN FD frame (EDL is set) -> alloc_canfd_skb()
You can have a CAN FD frame with a DLC of 8, which does *not* mean that you
have a CAN 2.0 frame.
> The issue i know is that candump seemed can not recognize remote frame reported
> by the driver.
Do you use the latest candump from
https://gitorious.org/linux-can/can-utils/
??
The latest candump switches the CAN_RAW socket into the mode to accept both
CAN *and* CAN FD frames and displays the frames correctly.
> Not sure if it's caused by canfd_frame used.
Yes. CAN FD frames do not have a RTR bit.
> Will test and check.
>
>> Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
>> FD frame.
>>
>> Of course you can use the struct canfd_frame in m_can_read_fifo() as the
>> layout of the struct can_frame is identical when filled with 'normal' CAN
>> frame content.
>>
>> But you need to distinguish whether it is a CAN or CAN FD frame when
>> allocating the skb based on the RX_BUF_EDL value.
>>
>
> Yes, i think it's good to do that.
> One obvious benefit is it saves memory at least.
The main point is that CAN frames and CAN FD frames are separated by this
(MTU) length information. It's not about saving memory.
A CAN FD frame with DLC 8 still has 64 data bytes inside it's data structure.
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] mlx4: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv
In-Reply-To: <1414626885.631.102.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 16:54:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4_en_rx_irq() and mlx4_en_tx_irq() run from hard interrupt context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ariel.elior
In-Reply-To: <1414627670.631.105.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 17:07:50 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> bnx2x_msix_fp_int() and bnx2x_interrupt() run from hard interrupt
> context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 20:52 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev
In-Reply-To: <20141030.155958.156984068627586090.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Wed, 29 Oct 2014 13:23:07 +0100
>
> > We could do that, if you prefer.
> >
> > I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> > then we want to enable 'passive' ecn for incoming connections only on
> > a particular route without announcing ecn to the peer. I haven't been
> > able to find any -- I think if you deem 'route to x' safe for ecn it
> > might as well be enabled for both initiator and responder. The original
> > patch would be sufficient for that.
> >
> > IOW, is 'ecn from a to b but not b to a' a sensible requirement?
>
> I think you have to apply the same logic for the sysctl (there's a
> reason to only support ECN passively) as you do for the route feature
> because you can logically look at the sysctl as applying to the
> default route.
Agreed, sysctl is comparable to default route.
And I think 'passive ecn' makes perfect sense for a default route.
But for a specific host/network?
Either I know that path to $x is ecn-safe (i.e. turn it on for both ends)
or I don't, in which case the global 'passive' default ("if peer requests
it they probably know what they're doing") is fine.
> > default at one point (almost no routers set CE bit at this time, perhaps
> > that would change if ecn usage is more widespread).
>
> Now you're talking.
>
> So, either passive ECN support makes sense or it does not. To me, no
> matter what the argument, it doesn't matter what realm (whole system,
> specific routes) you apply that argument to.
The passive mode was added 5 years ago via
commit 255cac91c3c9ce7dca7713b93ab03c75b7902e0e
(tcp: extend ECN sysctl to allow server-side only ECN), and I think the
commit log rationale makes sense.
So, what about changing the default to 1 in net-next?
We could add automatic 'no-ecn' to retransmitted syns to avoid
ecn blackholes (Daniel Borkmann has a patch for this), and, in case
ecn=1 causes too much breakage we can always revert (and re-consider ecn
per route settings as an intermediate step).
What do you think?
Thanks,
Florian
^ 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