* [PATCH RFC v2 net-next 05/25] net/ipv6: Update inet6_dump_addr to support NLM_F_DUMP_PROPER_HDR
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Update inet6_dump_addr to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifaddrmsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute is taken as
a request to influence the data returned. Only values suppored by the
dump handler are allowed to be non-0 or set in the request. At the moment
only the IFA_TARGET_NETNSID attribute is supported. Follow on patches
will support for other fields (e.g., honor ifa_index and only return data
for the given device index).
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv6/addrconf.c | 49 +++++++++++++++++++++++++++++++++++++++----------
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 375ea9d9869b..3382737df2a8 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5001,6 +5001,8 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
enum addr_type_t type)
{
+ struct netlink_ext_ack *extack = cb->extack;
+ const struct nlmsghdr *nlh = cb->nlh;
struct inet6_fill_args fillargs = {
.portid = NETLINK_CB(cb->skb).portid,
.seq = cb->nlh->nlmsg_seq,
@@ -5009,7 +5011,6 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
.type = type,
};
struct net *net = sock_net(skb->sk);
- struct nlattr *tb[IFA_MAX+1];
struct net *tgt_net = net;
int h, s_h;
int idx, ip_idx;
@@ -5022,17 +5023,45 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
- if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
- ifa_ipv6_policy, NULL) >= 0) {
- if (tb[IFA_TARGET_NETNSID]) {
- fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
+ if (nlh->nlmsg_flags & NLM_F_DUMP_PROPER_HDR) {
+ struct nlattr *tb[IFA_MAX+1];
+ struct ifaddrmsg *ifm;
+ int err, i;
+
+ if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*ifm))) {
+ NL_SET_ERR_MSG(extack, "Invalid header");
+ return -EINVAL;
+ }
+
+ ifm = nlmsg_data(nlh);
+ if (ifm->ifa_prefixlen || ifm->ifa_flags || ifm->ifa_scope) {
+ NL_SET_ERR_MSG(extack, "Invalid values in header for dump request");
+ return -EINVAL;
+ }
+ if (ifm->ifa_index) {
+ NL_SET_ERR_MSG(extack, "Filter by device index not supported");
+ return -EINVAL;
+ }
+
+ err = nlmsg_parse(nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
+ ifa_ipv6_policy, extack);
+ if (err < 0)
+ return err;
+
+ for (i = 0; i <= IFA_MAX; ++i) {
+ if (i == IFA_TARGET_NETNSID) {
+ fillargs.netnsid = nla_get_s32(tb[i]);
- tgt_net = rtnl_get_net_ns_capable(skb->sk,
- fillargs.netnsid);
- if (IS_ERR(tgt_net))
- return PTR_ERR(tgt_net);
+ tgt_net = rtnl_get_net_ns_capable(skb->sk,
+ fillargs.netnsid);
+ if (IS_ERR(tgt_net))
+ return PTR_ERR(tgt_net);
- fillargs.flags |= NLM_F_DUMP_FILTERED;
+ fillargs.flags |= NLM_F_DUMP_FILTERED;
+ } else if (tb[i]) {
+ NL_SET_ERR_MSG(extack, "Unsupported attribute in dump request");
+ return -EINVAL;
+ }
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
Signed-off-by: David Ahern <dsahern@gmail.com>
Acked-by: Christian Brauner <christian@brauner.io>
---
net/ipv6/addrconf.c | 59 +++++++++++++++++++++++++++++------------------------
1 file changed, 32 insertions(+), 27 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index a9a317322388..375ea9d9869b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4793,12 +4793,19 @@ static inline int inet6_ifaddr_msgsize(void)
+ nla_total_size(4) /* IFA_RT_PRIORITY */;
}
+enum addr_type_t {
+ UNICAST_ADDR,
+ MULTICAST_ADDR,
+ ANYCAST_ADDR,
+};
+
struct inet6_fill_args {
u32 portid;
u32 seq;
int event;
unsigned int flags;
int netnsid;
+ enum addr_type_t type;
};
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
@@ -4930,39 +4937,28 @@ static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca,
return 0;
}
-enum addr_type_t {
- UNICAST_ADDR,
- MULTICAST_ADDR,
- ANYCAST_ADDR,
-};
-
/* called with rcu_read_lock() */
static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
- struct netlink_callback *cb, enum addr_type_t type,
- int s_ip_idx, int *p_ip_idx, int netnsid)
+ struct netlink_callback *cb,
+ int s_ip_idx, int *p_ip_idx,
+ struct inet6_fill_args *fillargs)
{
- struct inet6_fill_args fillargs = {
- .portid = NETLINK_CB(cb->skb).portid,
- .seq = cb->nlh->nlmsg_seq,
- .flags = NLM_F_MULTI,
- .netnsid = netnsid,
- };
struct ifmcaddr6 *ifmca;
struct ifacaddr6 *ifaca;
int err = 1;
int ip_idx = *p_ip_idx;
read_lock_bh(&idev->lock);
- switch (type) {
+ switch (fillargs->type) {
case UNICAST_ADDR: {
struct inet6_ifaddr *ifa;
- fillargs.event = RTM_NEWADDR;
+ fillargs->event = RTM_NEWADDR;
/* unicast address incl. temp addr */
list_for_each_entry(ifa, &idev->addr_list, if_list) {
if (++ip_idx < s_ip_idx)
continue;
- err = inet6_fill_ifaddr(skb, ifa, &fillargs);
+ err = inet6_fill_ifaddr(skb, ifa, fillargs);
if (err < 0)
break;
nl_dump_check_consistent(cb, nlmsg_hdr(skb));
@@ -4970,26 +4966,26 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
break;
}
case MULTICAST_ADDR:
- fillargs.event = RTM_GETMULTICAST;
+ fillargs->event = RTM_GETMULTICAST;
/* multicast address */
for (ifmca = idev->mc_list; ifmca;
ifmca = ifmca->next, ip_idx++) {
if (ip_idx < s_ip_idx)
continue;
- err = inet6_fill_ifmcaddr(skb, ifmca, &fillargs);
+ err = inet6_fill_ifmcaddr(skb, ifmca, fillargs);
if (err < 0)
break;
}
break;
case ANYCAST_ADDR:
- fillargs.event = RTM_GETANYCAST;
+ fillargs->event = RTM_GETANYCAST;
/* anycast address */
for (ifaca = idev->ac_list; ifaca;
ifaca = ifaca->aca_next, ip_idx++) {
if (ip_idx < s_ip_idx)
continue;
- err = inet6_fill_ifacaddr(skb, ifaca, &fillargs);
+ err = inet6_fill_ifacaddr(skb, ifaca, fillargs);
if (err < 0)
break;
}
@@ -5005,10 +5001,16 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
enum addr_type_t type)
{
+ struct inet6_fill_args fillargs = {
+ .portid = NETLINK_CB(cb->skb).portid,
+ .seq = cb->nlh->nlmsg_seq,
+ .flags = NLM_F_MULTI,
+ .netnsid = -1,
+ .type = type,
+ };
struct net *net = sock_net(skb->sk);
struct nlattr *tb[IFA_MAX+1];
struct net *tgt_net = net;
- int netnsid = -1;
int h, s_h;
int idx, ip_idx;
int s_idx, s_ip_idx;
@@ -5023,11 +5025,14 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
ifa_ipv6_policy, NULL) >= 0) {
if (tb[IFA_TARGET_NETNSID]) {
- netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
+ fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
- tgt_net = rtnl_get_net_ns_capable(skb->sk, netnsid);
+ tgt_net = rtnl_get_net_ns_capable(skb->sk,
+ fillargs.netnsid);
if (IS_ERR(tgt_net))
return PTR_ERR(tgt_net);
+
+ fillargs.flags |= NLM_F_DUMP_FILTERED;
}
}
@@ -5046,8 +5051,8 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
if (!idev)
goto cont;
- if (in6_dump_addrs(idev, skb, cb, type,
- s_ip_idx, &ip_idx, netnsid) < 0)
+ if (in6_dump_addrs(idev, skb, cb, s_ip_idx, &ip_idx,
+ &fillargs) < 0)
goto done;
cont:
idx++;
@@ -5058,7 +5063,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
cb->args[0] = h;
cb->args[1] = idx;
cb->args[2] = ip_idx;
- if (netnsid >= 0)
+ if (fillargs.netnsid >= 0)
put_net(tgt_net);
return skb->len;
--
2.11.0
^ permalink raw reply related
* [PATCH RFC v2 net-next 04/25] net/ipv4: Update inet_dump_ifaddr to support NLM_F_DUMP_PROPER_HDR
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Update inet_dump_ifaddr to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifaddrmsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute is taken as
a request to influence the data returned. Only values suppored by the
dump handler are allowed to be non-0 or set in the request. At the moment
only the IFA_TARGET_NETNSID attribute is supported. Follow on patches
will support for other fields (e.g., honor ifa_index and only return data
for the given device index).
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/devinet.c | 52 +++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 44d931a3cd50..c27537f568f0 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1661,15 +1661,15 @@ static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa,
static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
+ struct netlink_ext_ack *extack = cb->extack;
+ const struct nlmsghdr *nlh = cb->nlh;
struct inet_fill_args fillargs = {
.portid = NETLINK_CB(cb->skb).portid,
- .seq = cb->nlh->nlmsg_seq,
+ .seq = nlh->nlmsg_seq,
.event = RTM_NEWADDR,
- .flags = NLM_F_MULTI,
.netnsid = -1,
};
struct net *net = sock_net(skb->sk);
- struct nlattr *tb[IFA_MAX+1];
struct net *tgt_net = net;
int h, s_h;
int idx, s_idx;
@@ -1683,15 +1683,45 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
- if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
- ifa_ipv4_policy, NULL) >= 0) {
- if (tb[IFA_TARGET_NETNSID]) {
- fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
+ if (nlh->nlmsg_flags & NLM_F_DUMP_PROPER_HDR) {
+ struct nlattr *tb[IFA_MAX+1];
+ struct ifaddrmsg *ifm;
+ int err, i;
+
+ if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*ifm))) {
+ NL_SET_ERR_MSG(extack, "Invalid header");
+ return -EINVAL;
+ }
+
+ ifm = nlmsg_data(nlh);
+ if (ifm->ifa_prefixlen || ifm->ifa_flags || ifm->ifa_scope) {
+ NL_SET_ERR_MSG(extack, "Invalid values in header for dump request");
+ return -EINVAL;
+ }
+ if (ifm->ifa_index) {
+ NL_SET_ERR_MSG(extack, "Filter by device index not supported");
+ return -EINVAL;
+ }
- tgt_net = rtnl_get_net_ns_capable(skb->sk,
- fillargs.netnsid);
- if (IS_ERR(tgt_net))
- return PTR_ERR(tgt_net);
+ err = nlmsg_parse(nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
+ ifa_ipv4_policy, extack);
+ if (err < 0)
+ return err;
+
+ for (i = 0; i <= IFA_MAX; ++i) {
+ if (i == IFA_TARGET_NETNSID) {
+ fillargs.netnsid = nla_get_s32(tb[i]);
+
+ tgt_net = rtnl_get_net_ns_capable(skb->sk,
+ fillargs.netnsid);
+ if (IS_ERR(tgt_net))
+ return PTR_ERR(tgt_net);
+
+ fillargs.flags |= NLM_F_DUMP_FILTERED;
+ } else if (tb[i]) {
+ NL_SET_ERR_MSG(extack, "Unsupported attribute in dump request");
+ return -EINVAL;
+ }
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
From: David Ahern <dsahern@gmail.com>
There are many use cases where a user wants to influence what is
returned in a dump for some rtnetlink command: one is wanting data
for a different namespace than the one the request is received and
another is limiting the amount of data returned in the dump to a
specific set of interest to userspace, reducing the cpu overhead of
both kernel and userspace. Unfortunately, the kernel has historically
not been strict with checking for the proper header or checking the
values passed in the header. This lenient implementation has allowed
iproute2 and other packages to pass any struct or data in the dump
request as long as the family is the first byte. For example, ifinfomsg
struct is used by iproute2 for all generic dump requests - links,
addresses, routes and rules when it is really only valid for link
requests.
There is 1 is example where the kernel deals with the wrong struct: link
dumps after VF support was added. Older iproute2 was sending rtgenmsg as
the header instead of ifinfomsg so a patch was added to try and detect
old userspace vs new:
e5eca6d41f53 ("rtnetlink: fix userspace API breakage for iproute2 < v3.9.0")
The latest example is Christian's patch set wanting to return addresses for
a target namespace. It guesses the header struct is an ifaddrmsg and if it
guesses wrong a netlink warning is generated in the kernel log on every
address dump which is unacceptable.
Another example where the kernel is a bit lenient is route dumps: iproute2
can send either a request with either ifinfomsg or a rtmsg as the header
struct, yet the kernel always treats the header as an rtmsg (see
inet_dump_fib and rtm_flags check). The header inconsistency impacts the
ability to add kernel side filters for route dumps - a necessary feature
for scale setups with 100k+ routes.
How to resolve the problem of not breaking old userspace yet be able to
move forward with new features such as kernel side filtering which are
crucial for efficient operation at high scale?
This patch set addresses the problem by adding a new netlink flag,
NLM_F_DUMP_PROPER_HDR, that userspace can set to say "I have a clue, and
I am sending the right header struct" and that the struct fields and any
attributes after it should be used for filtering the data returned in the
dump.
Kernel side, the dump handlers are updated to verify the message contains
at least the expected header struct:
RTM_GETLINK: ifinfomsg
RTM_GETADDR: ifaddrmsg
RTM_GETMULTICAST: ifaddrmsg
RTM_GETANYCAST: ifaddrmsg
RTM_GETADDRLABEL: ifaddrlblmsg
RTM_GETROUTE: rtmsg
RTM_GETSTATS: if_stats_msg
RTM_GETNEIGH: ndmsg
RTM_GETNEIGHTBL: ndtmsg
RTM_GETNSID: rtnl_net_dumpid
RTM_GETRULE: fib_rule_hdr
RTM_GETNETCONF: netconfmsg
RTM_GETMDB: br_port_msg
And then every field in the header struct should be 0 with the exception
of the family. There are a few exceptions to this rule where the kernel
already influences the data returned by values in the struct. Next the
message should not contain attributes unless the kernel implements
filtering for it. Any unexpected data causes the dump to fail with EINVAL.
If the new flag is honored by the kernel and the dump contents adjusted
by any data passed in the request, the dump handler can set the
NLM_F_DUMP_FILTERED flag in the netlink message header.
As an example of how this new NLM_F_DUMP_PROPER_HDR can be leveraged,
the last 6 patch add filtering of route dumps based on table id, protocol,
tos, flags, scope, and egress device.
David Ahern (25):
net/netlink: Pass extack to dump callbacks
net/ipv6: Refactor address dump to push inet6_fill_args to
in6_dump_addrs
netlink: introduce NLM_F_DUMP_PROPER_HDR flag
net/ipv4: Update inet_dump_ifaddr to support NLM_F_DUMP_PROPER_HDR
net/ipv6: Update inet6_dump_addr to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_dump_ifinfo to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_bridge_getlink to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_stats_dump to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update inet6_dump_ifinfo to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update ipmr_rtm_dumplink to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update fib dumps to support NLM_F_DUMP_PROPER_HDR
net/neigh: Refactor dump filter handling
net/neighbor: Update neigh_dump_info to support NLM_F_DUMP_PROPER_HDR
net/neighbor: Update neightbl_dump_info to support
NLM_F_DUMP_PROPER_HDR
net/namespace: Update rtnl_net_dumpid to support NLM_F_DUMP_PROPER_HDR
net/fib_rules: Update fib_nl_dumprule to support NLM_F_DUMP_PROPER_HDR
net/ipv6: Update ip6addrlbl_dump to support NLM_F_DUMP_PROPER_HDR
net: Update netconf dump handlers to support NLM_F_DUMP_PROPER_HDR
net/bridge: Update br_mdb_dump to support NLM_F_DUMP_PROPER_HDR
net: Add struct for fib dump filter
net/ipv4: Plumb support for filtering route dumps
net/ipv6: Plumb support for filtering route dumps
net/mpls: Plumb support for filtering route dumps
net: Plumb support for filtering ipv4 and ipv6 multicast route dumps
net: Enable kernel side filtering of route dumps
include/linux/mroute_base.h | 5 +-
include/linux/netlink.h | 2 +
include/net/ip6_route.h | 1 +
include/net/ip_fib.h | 16 +++-
include/uapi/linux/netlink.h | 1 +
net/bridge/br_mdb.c | 20 ++++-
net/core/fib_rules.c | 25 +++++-
net/core/neighbour.c | 136 +++++++++++++++++++++++--------
net/core/net_namespace.c | 8 ++
net/core/rtnetlink.c | 185 +++++++++++++++++++++++++++++++++----------
net/ipv4/devinet.c | 74 +++++++++++++----
net/ipv4/fib_frontend.c | 76 +++++++++++++++++-
net/ipv4/fib_trie.c | 33 +++++---
net/ipv4/ipmr.c | 44 +++++++++-
net/ipv4/ipmr_base.c | 42 +++++++++-
net/ipv6/addrconf.c | 160 ++++++++++++++++++++++++++++---------
net/ipv6/addrlabel.c | 25 +++++-
net/ipv6/ip6_fib.c | 23 +++++-
net/ipv6/ip6mr.c | 12 ++-
net/ipv6/route.c | 36 ++++++---
net/mpls/af_mpls.c | 82 ++++++++++++++++++-
net/netlink/af_netlink.c | 20 +++--
22 files changed, 860 insertions(+), 166 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH RFC v2 net-next 06/25] rtnetlink: Update rtnl_dump_ifinfo to support NLM_F_DUMP_PROPER_HDR
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Update rtnl_dump_ifinfo to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifinfomsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute is taken as
a request to influence the data returned. Only values supported by the
dump handler are allowed to be non-0 or set in the request. At the moment
only the IFA_TARGET_NETNSID, IFLA_EXT_MASK, IFLA_MASTER, and IFLA_LINKINFO
attributes are supported.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/core/rtnetlink.c | 106 ++++++++++++++++++++++++++++++++++++---------------
1 file changed, 75 insertions(+), 31 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index da91b38297d3..2bf4b9916ca2 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1880,6 +1880,9 @@ EXPORT_SYMBOL_GPL(rtnl_get_net_ns_capable);
static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
{
+ struct netlink_ext_ack *extack = cb->extack;
+ const struct nlmsghdr *nlh = cb->nlh;
+ bool proper_hdr = !!(nlh->nlmsg_flags & NLM_F_DUMP_PROPER_HDR);
struct net *net = sock_net(skb->sk);
struct net *tgt_net = net;
int h, s_h;
@@ -1892,46 +1895,88 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
unsigned int flags = NLM_F_MULTI;
int master_idx = 0;
int netnsid = -1;
- int err;
+ int err, i;
int hdrlen;
s_h = cb->args[0];
s_idx = cb->args[1];
- /* A hack to preserve kernel<->userspace interface.
- * The correct header is ifinfomsg. It is consistent with rtnl_getlink.
- * However, before Linux v3.9 the code here assumed rtgenmsg and that's
- * what iproute2 < v3.9.0 used.
- * We can detect the old iproute2. Even including the IFLA_EXT_MASK
- * attribute, its netlink message is shorter than struct ifinfomsg.
- */
- hdrlen = nlmsg_len(cb->nlh) < sizeof(struct ifinfomsg) ?
- sizeof(struct rtgenmsg) : sizeof(struct ifinfomsg);
+ if (proper_hdr) {
+ struct ifinfomsg *ifm;
- if (nlmsg_parse(cb->nlh, hdrlen, tb, IFLA_MAX,
- ifla_policy, NULL) >= 0) {
- if (tb[IFLA_TARGET_NETNSID]) {
- netnsid = nla_get_s32(tb[IFLA_TARGET_NETNSID]);
- tgt_net = rtnl_get_net_ns_capable(skb->sk, netnsid);
- if (IS_ERR(tgt_net)) {
- tgt_net = net;
- netnsid = -1;
- }
+ hdrlen = sizeof(*ifm);
+ if (nlh->nlmsg_len < nlmsg_msg_size(hdrlen)) {
+ NL_SET_ERR_MSG(extack, "Invalid header");
+ return -EINVAL;
}
- if (tb[IFLA_EXT_MASK])
- ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
-
- if (tb[IFLA_MASTER])
- master_idx = nla_get_u32(tb[IFLA_MASTER]);
-
- if (tb[IFLA_LINKINFO])
- kind_ops = linkinfo_to_kind_ops(tb[IFLA_LINKINFO]);
+ ifm = nlmsg_data(nlh);
+ if (ifm->__ifi_pad || ifm->ifi_type || ifm->ifi_flags ||
+ ifm->ifi_change) {
+ NL_SET_ERR_MSG(extack, "Invalid values in header for dump request");
+ return -EINVAL;
+ }
+ if (ifm->ifi_index) {
+ NL_SET_ERR_MSG(extack, "Filter by device index not supported");
+ return -EINVAL;
+ }
+ } else {
+ /* A hack to preserve kernel<->userspace interface.
+ * The correct header is ifinfomsg. It is consistent with
+ * rtnl_getlink. However, before Linux v3.9 the code here
+ * assumed rtgenmsg and that's what iproute2 < v3.9.0 used.
+ * We can detect the old iproute2. Even including the
+ * IFLA_EXT_MASK attribute, its netlink message is shorter
+ * than struct ifinfomsg.
+ */
+ hdrlen = nlmsg_len(nlh) < sizeof(struct ifinfomsg) ?
+ sizeof(struct rtgenmsg) : sizeof(struct ifinfomsg);
+ }
- if (master_idx || kind_ops)
- flags |= NLM_F_DUMP_FILTERED;
+ err = nlmsg_parse(nlh, hdrlen, tb, IFLA_MAX, ifla_policy, extack);
+ if (err < 0) {
+ if (proper_hdr) {
+ NL_SET_ERR_MSG(extack, "Failed to parse link attributes");
+ return -EINVAL;
+ }
+ goto walk_entries;
+ }
+
+ for (i = 0; i <= IFLA_MAX; ++i) {
+ switch (i) {
+ case IFLA_TARGET_NETNSID:
+ if (tb[i]) {
+ netnsid = nla_get_s32(tb[i]);
+ tgt_net = rtnl_get_net_ns_capable(skb->sk,
+ netnsid);
+ if (IS_ERR(tgt_net))
+ return PTR_ERR(tgt_net);
+ }
+ break;
+ case IFLA_EXT_MASK:
+ if (tb[i])
+ ext_filter_mask = nla_get_u32(tb[i]);
+ break;
+ case IFLA_MASTER:
+ if (tb[i])
+ master_idx = nla_get_u32(tb[i]);
+ break;
+ case IFLA_LINKINFO:
+ if (tb[i])
+ kind_ops = linkinfo_to_kind_ops(tb[i]);
+ break;
+ default:
+ if (proper_hdr && tb[i]) {
+ NL_SET_ERR_MSG(extack, "Unsupported attribute in dump request");
+ return -EINVAL;
+ }
+ }
}
+ if (master_idx || kind_ops || netnsid >= 0)
+ flags |= NLM_F_DUMP_FILTERED;
+
+walk_entries:
for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
idx = 0;
head = &tgt_net->dev_index_head[h];
@@ -1943,8 +1988,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
err = rtnl_fill_ifinfo(skb, dev, net,
RTM_NEWLINK,
NETLINK_CB(cb->skb).portid,
- cb->nlh->nlmsg_seq, 0,
- flags,
+ nlh->nlmsg_seq, 0, flags,
ext_filter_mask, 0, NULL, 0,
netnsid);
--
2.11.0
^ permalink raw reply related
* [PATCH RFC v2 net-next 01/25] net/netlink: Pass extack to dump callbacks
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Pass extack to dump callbacks by adding extack to netlink_dump_control,
transferring to netlink_callback and adding to the netlink_dump. Update
rtnetlink as the first user. Update netlink_dump to add any message after
the dump_done_errno.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/linux/netlink.h | 2 ++
net/core/rtnetlink.c | 1 +
net/netlink/af_netlink.c | 20 +++++++++++++++-----
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 71f121b66ca8..8fc90308a653 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -176,6 +176,7 @@ struct netlink_callback {
void *data;
/* the module that dump function belong to */
struct module *module;
+ struct netlink_ext_ack *extack;
u16 family;
u16 min_dump_alloc;
unsigned int prev_seq, seq;
@@ -197,6 +198,7 @@ struct netlink_dump_control {
int (*done)(struct netlink_callback *);
void *data;
struct module *module;
+ struct netlink_ext_ack *extack;
u16 min_dump_alloc;
};
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 35162e1b06ad..da91b38297d3 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4689,6 +4689,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
.dump = dumpit,
.min_dump_alloc = min_dump_alloc,
.module = owner,
+ .extack = extack
};
err = netlink_dump_start(rtnl, skb, nlh, &c);
/* netlink_dump_start() will keep a reference on
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index e3a0538ec0be..7094156c94f0 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -129,7 +129,7 @@ static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
"nlk_cb_mutex-MAX_LINKS"
};
-static int netlink_dump(struct sock *sk);
+static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack);
/* nl_table locking explained:
* Lookup and traversal are protected with an RCU read-side lock. Insertion
@@ -1981,7 +1981,7 @@ static int netlink_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (nlk->cb_running &&
atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
- ret = netlink_dump(sk);
+ ret = netlink_dump(sk, NULL);
if (ret) {
sk->sk_err = -ret;
sk->sk_error_report(sk);
@@ -2168,7 +2168,7 @@ EXPORT_SYMBOL(__nlmsg_put);
* It would be better to create kernel thread.
*/
-static int netlink_dump(struct sock *sk)
+static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack)
{
struct netlink_sock *nlk = nlk_sk(sk);
struct netlink_callback *cb;
@@ -2222,8 +2222,11 @@ static int netlink_dump(struct sock *sk)
skb_reserve(skb, skb_tailroom(skb) - alloc_size);
netlink_skb_set_owner_r(skb, sk);
- if (nlk->dump_done_errno > 0)
+ if (nlk->dump_done_errno > 0) {
+ cb->extack = extack;
nlk->dump_done_errno = cb->dump(skb, cb);
+ cb->extack = NULL;
+ }
if (nlk->dump_done_errno > 0 ||
skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) {
@@ -2246,6 +2249,12 @@ static int netlink_dump(struct sock *sk)
memcpy(nlmsg_data(nlh), &nlk->dump_done_errno,
sizeof(nlk->dump_done_errno));
+ if (extack && extack->_msg && nlk->flags & NETLINK_F_EXT_ACK) {
+ nlh->nlmsg_flags |= NLM_F_ACK_TLVS;
+ if (!nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
+ nlmsg_end(skb, nlh);
+ }
+
if (sk_filter(sk, skb))
kfree_skb(skb);
else
@@ -2307,6 +2316,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
cb->module = control->module;
cb->min_dump_alloc = control->min_dump_alloc;
cb->skb = skb;
+ cb->extack = control->extack;
if (control->start) {
ret = control->start(cb);
@@ -2319,7 +2329,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
mutex_unlock(nlk->cb_mutex);
- ret = netlink_dump(sk);
+ ret = netlink_dump(sk, cb->extack);
sock_put(sk);
--
2.11.0
^ permalink raw reply related
* [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: David Ahern @ 2018-10-02 0:28 UTC (permalink / raw)
To: netdev, davem; +Cc: christian, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
kernel that it believes it is sending the right header struct for the
dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
Setting the flag in the netlink message header indicates to the kernel
it should do rigid checking on all data passed in the dump request and
filter the data returned based on data passed in.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/uapi/linux/netlink.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 776bc92e9118..e722bed88dee 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -57,6 +57,7 @@ struct nlmsghdr {
#define NLM_F_ECHO 0x08 /* Echo this request */
#define NLM_F_DUMP_INTR 0x10 /* Dump was inconsistent due to sequence change */
#define NLM_F_DUMP_FILTERED 0x20 /* Dump was filtered as requested */
+#define NLM_F_DUMP_PROPER_HDR 0x40 /* Dump request has the proper header for type */
/* Modifiers to GET request */
#define NLM_F_ROOT 0x100 /* specify tree root */
--
2.11.0
^ permalink raw reply related
* Re: [RFC PATCH bpf-next v3 4/7] bpf: add bpf queue and stack maps
From: Alexei Starovoitov @ 2018-10-02 0:26 UTC (permalink / raw)
To: Mauricio Vasquez; +Cc: daniel, netdev
In-Reply-To: <12a0d7d2-9590-b44f-803a-a00eefe611c1@polito.it>
On Mon, Oct 01, 2018 at 08:11:43AM -0500, Mauricio Vasquez wrote:
> > > > +BPF_CALL_3(bpf_map_pop_elem, struct bpf_map *, map, void *,
> > > > value, u32, size)
> > > > +{
> > > > + void *ptr;
> > > > +
> > > > + if (map->value_size != size)
> > > > + return -EINVAL;
> > > > +
> > > > + ptr = map->ops->map_lookup_and_delete_elem(map, NULL);
> > > > + if (!ptr)
> > > > + return -ENOENT;
> > > > +
> > > > + switch (size) {
> > > > + case 1:
> > > > + *(u8 *) value = *(u8 *) ptr;
> > > > + break;
> > > > + case 2:
> > > > + *(u16 *) value = *(u16 *) ptr;
> > > > + break;
> > > > + case 4:
> > > > + *(u32 *) value = *(u32 *) ptr;
> > > > + break;
> > > > + case 8:
> > > > + *(u64 *) value = *(u64 *) ptr;
> > > > + break;
> > > this is inefficient. can we pass value ptr into ops and let it
> > > populate it?
> >
> > I don't think so, doing that implies that look_and_delete will be a
> > per-value op, while other ops in maps are per-reference.
> > For instance, how to change it in the case of peek helper that is using
> > the lookup operation?, we cannot change the signature of the lookup
> > operation.
> >
> > This is something that worries me a little bit, we are creating new
> > per-value helpers based on already existing per-reference operations,
> > this is not probably the cleanest way. Here we are at the beginning of
> > the discussion once again, how should we map helpers and syscalls to
> > ops.
> >
> > What about creating pop/peek/push ops, mapping helpers one to one and
> > adding some logic into syscall.c to call the correct operation in case
> > the map is stack/queue?
> > Syscall mapping would be:
> > bpf_map_lookup_elem() -> peek
> > bpf_map_lookup_and_delete_elem() -> pop
> > bpf_map_update_elem() -> push
> >
> > Does it make sense?
>
> Hello Alexei,
>
> Do you have any feedback on this specific part?
Indeed. It seems push/pop ops will be cleaner.
I still think that peek() is useless due to races.
So BPF_MAP_UPDATE_ELEM syscall cmd will map to 'push' ops
and new BPF_MAP_LOOKUP_AND_DELETE_ELEM will map to 'pop' ops.
right?
^ permalink raw reply
* Re: [PATCH net 2/5] net/smc: remove duplicate mutex_unlock
From: Heiko Carstens @ 2018-10-02 6:46 UTC (permalink / raw)
To: Ursula Braun
Cc: Dan Carpenter, kbuild, kbuild-all, davem, netdev, linux-s390,
schwidefsky, raspl, linux-kernel
In-Reply-To: <c0fe2ae3-38b4-5023-9140-20f7acac6028@linux.ibm.com>
On Mon, Oct 01, 2018 at 05:22:22PM +0200, Ursula Braun wrote:
>
> > 3b2dec260 Hans Wippel 2018-05-18 1282 /* finish worker */
> > c69342ef9 Ursula Braun 2018-09-18 1283 if (!ism_supported) {
> > c69342ef9 Ursula Braun 2018-09-18 1284 if (smc_listen_rdma_finish(new_smc, &cclc, local_contact))
> > c69342ef9 Ursula Braun 2018-09-18 1285 return;
> > ^^^^^^
> > We need to mutex_unlock(&smc_create_lgr_pending); before the return.
> >
>
> The smatch warning is not necessary, since the mutex_unlock(&smc_create_lgr_pending)
> for this case is done within smc_listen_rdma_finish().
>
> > c69342ef9 Ursula Braun 2018-09-18 1286 }
> > 3b2dec260 Hans Wippel 2018-05-18 1287 smc_conn_save_peer_info(new_smc, &cclc);
> > 3b2dec260 Hans Wippel 2018-05-18 1288 mutex_unlock(&smc_create_lgr_pending);
> > 3b2dec260 Hans Wippel 2018-05-18 @1289 smc_listen_out_connected(new_smc);
> > a046d57da Ursula Braun 2017-01-09 1290 }
> > a046d57da Ursula Braun 2017-01-09 1291
> >
> > ---
> > 0-DAY kernel test infrastructure Open Source Technology Center
> > https://lists.01.org/pipermail/kbuild-all Intel Corporation
> >
>
> But you could argue the code confuses smatch and other readers. Thus I could improve
> readability with a patch like this:
Yes, please.
> ---
> net/smc/af_smc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1184,7 +1184,6 @@ static int smc_listen_rdma_finish(struct
> return 0;
>
> decline:
> - mutex_unlock(&smc_create_lgr_pending);
> smc_listen_decline(new_smc, reason_code, local_contact);
> return reason_code;
> }
The lonely mutex_unlock() also _looks_ like a bug ;)
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Richard Weinberger @ 2018-10-02 6:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jason A. Donenfeld, Herbert Xu, ebiggers, LKML, netdev,
linux-crypto, David S. Miller, Greg KH
In-Reply-To: <CAKv+Gu8fr_qADiTJH05nVWF7Yi3U722nfKJsMaRE9CP3YjNBbg@mail.gmail.com>
On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On 2 October 2018 at 05:45, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > Hi Herbert,
> >
> > On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >> > I would also strongly prefer that all crypto work is taken through
> >> > Herbert's tree, so we have a coherent view of it before it goes
> >> > upstream.
> >>
> >> I agree. I don't have any problems with the zinc code living in
> >> its own git tree. But any upstream merges should definitely go
> >> through the crypto tree because the inherent ties between the two
> >> code-base.
> >
> > I can send you pull requests then if there are development cycles when
> > there are in fact relations between the two trees. I'll update the
> > commit message describing Zinc to include this.
> >
>
> Can you explain why you it is so important to you that your changes
> remain outside the crypto tree?
>
> Also, I still think the name Zinc (zinc is not crypto/) is needlessly
> divisive and condescending, and unsaying it (in v2 and up) doesn't
> really work on the Internet (especially since you are still repeating
> it in your conference talk.)
I've been following the drama^Wdiscussion on the zinc for a long time now
and I also think that "zinc" is a misleading name.
Jason, you seem to hate the existing crypto framework with passion,
and the name reflects that.
Since we all agree that the framework can do better and your patches actually
make it better, please just rename it to something that reflects what
it is, a base
framework. I think Ard already suggested "crypto/base/" or "crypto/core/".
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH RESEND] net: phy: Convert to using %pOFn instead of device_node.name
From: David Miller @ 2018-10-02 6:30 UTC (permalink / raw)
To: robh; +Cc: linux-kernel, andrew, netdev, f.fainelli
In-Reply-To: <20180928220459.11385-1-robh@kernel.org>
From: Rob Herring <robh@kernel.org>
Date: Fri, 28 Sep 2018 17:04:59 -0500
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> David, Resending because you superseded this one for some reason. It
> shouldn't be. Perhaps because the subject was similar to others?
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Revert "openvswitch: Fix template leak in error cases."
From: David Miller @ 2018-10-02 6:21 UTC (permalink / raw)
To: fbl-H+wXaHxf7aLQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180928175534.13590-1-fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Flavio Leitner <fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Fri, 28 Sep 2018 14:55:34 -0300
> This reverts commit 90c7afc96cbbd77f44094b5b651261968e97de67.
>
> When the commit was merged, the code used nf_ct_put() to free
> the entry, but later on commit 76644232e612 ("openvswitch: Free
> tmpl with tmpl_free.") replaced that with nf_ct_tmpl_free which
> is a more appropriate. Now the original problem is removed.
>
> Then 44d6e2f27328 ("net: Replace NF_CT_ASSERT() with WARN_ON().")
> replaced a debug assert with a WARN_ON() which is trigged now.
>
> Signed-off-by: Flavio Leitner <fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] selftests/tls: Fix recv(MSG_PEEK) & splice() test cases
From: David Miller @ 2018-10-02 6:19 UTC (permalink / raw)
To: vakul.garg
Cc: netdev, linux-kselftest, linux-kernel, shuah, davejwatson,
doronrk
In-Reply-To: <20180928161808.10363-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Fri, 28 Sep 2018 21:48:08 +0530
> TLS test cases splice_from_pipe, send_and_splice &
> recv_peek_multiple_records expect to receive a given nummber of bytes
> and then compare them against the number of bytes which were sent.
> Therefore, system call recv() must not return before receiving the
> requested number of bytes, otherwise the subsequent memcmp() fails.
> This patch passes MSG_WAITALL flag to recv() so that it does not return
> prematurely before requested number of bytes are copied to receive
> buffer.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: Fix rndis_per_packet_info internal field initialization
From: David Miller @ 2018-10-02 6:15 UTC (permalink / raw)
To: haiyangz, haiyangz
Cc: netdev, kys, sthemmin, olaf, vkuznets, devel, linux-kernel
In-Reply-To: <20180928144123.11926-1-haiyangz@linuxonhyperv.com>
From: Haiyang Zhang <haiyangz@linuxonhyperv.com>
Date: Fri, 28 Sep 2018 14:41:23 +0000
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The RSC feature -- a bit field "internal" was added here with total
> size unchanged:
> struct rndis_per_packet_info {
> u32 size;
> u32 type:31;
> u32 internal:1;
> u32 ppi_offset;
> };
>
> On TX path, we put rndis msg into skb head room, which is not zeroed
> before passing to us. We do not use the "internal" field in TX path,
> but it may impact older hosts which use the entire 32 bits as "type".
>
> To fix the bug, this patch sets the field "internal" to zero.
>
> Fixes: c8e4eff4675f ("hv_netvsc: Add support for LRO/RSC in the vSwitch")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* RE: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
From: Madalin-cristian Bucur @ 2018-10-02 6:07 UTC (permalink / raw)
To: Leo Li
Cc: Roy Pledge, Claudiu Manoil, Catalin Marinas, Scott Wood,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev, lkml, netdev@vger.kernel.org
In-Reply-To: <CADRPPNQgGAYTCmppyxPwQnnC433QLm21D5iq_4EvSj0LrsAxGQ@mail.gmail.com>
> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Tuesday, October 2, 2018 12:50 AM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Cc: Roy Pledge <roy.pledge@nxp.com>; Claudiu Manoil
> <claudiu.manoil@nxp.com>; Catalin Marinas <catalin.marinas@arm.com>; Scott
> Wood <oss@buserror.net>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; linuxppc-dev
> <linuxppc-dev@lists.ozlabs.org>; lkml <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
>
> On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur <madalin.bucur@nxp.com>
> wrote:
> >
> > Export the API required to control the QMan portal interrupt coalescing
> > settings.
>
> These are new APIs not just old APIs being exported. What is the user
> of these APIs? Is the user being submitted? We cannot have APIs in
> kernel that has no users.
Hi,
These are new APIs that will be used in the DPAA Ethernet driver.
Changes for the DPAA QBMan and DPAA Ethernet follow different paths upstream
so the Ethernet driver patch that makes use of these APIs will be sent when
these changes reach the net-next/master tree.
Regards,
Madalin
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Ard Biesheuvel @ 2018-10-02 6:04 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Herbert Xu, Eric Biggers, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman
In-Reply-To: <CAHmME9piX1kbUhOBcUKVdecr45EjxuruxYuMTepfXVvRrkVmyg@mail.gmail.com>
On 2 October 2018 at 05:45, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Herbert,
>
> On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> > I would also strongly prefer that all crypto work is taken through
>> > Herbert's tree, so we have a coherent view of it before it goes
>> > upstream.
>>
>> I agree. I don't have any problems with the zinc code living in
>> its own git tree. But any upstream merges should definitely go
>> through the crypto tree because the inherent ties between the two
>> code-base.
>
> I can send you pull requests then if there are development cycles when
> there are in fact relations between the two trees. I'll update the
> commit message describing Zinc to include this.
>
Can you explain why you it is so important to you that your changes
remain outside the crypto tree?
Also, I still think the name Zinc (zinc is not crypto/) is needlessly
divisive and condescending, and unsaying it (in v2 and up) doesn't
really work on the Internet (especially since you are still repeating
it in your conference talk.)
^ permalink raw reply
* Re: [PATCH v2 net-next 7/8] net: ethernet: xgbe: expand PHY_GBIT_FEAUTRES
From: Andrew Lunn @ 2018-10-01 23:23 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David Miller, netdev, Florian Fainelli, Maxime Chevallier
In-Reply-To: <a387133e-7887-e7a3-4f70-b97a45ccbe07@cogentembedded.com>
On Sun, Sep 30, 2018 at 11:41:00AM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 9/30/2018 12:04 AM, Andrew Lunn wrote:
>
> >The macro PHY_GBIT_FEAUTRES needs to change into a bitmap in order to
> >support link_modes. Remove its use from xgde by replacing it with its
> >definition.
> >
> >Probably, the current behavior is wrong. It probably should be
> >ANDing not assigning.
>
> ORing, maybe?
Hi Sergei
It is hard to know what was intended here.
By assigning these speeds, if the PHY does not actually support 1Gbps,
that information is going to be overwritten. So it should really be
ANDing with that the MAC supports. ORing would have the same problem.
This assignment is also clearing out an TP, AUI, BNC bits which might
be set.
Since i don't really know what the intention is here, i'm just going
to leave it alone.
>
> >Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >---
> >v2
> >Remove unneeded ()
>
> Really? :-)
I did not say all unneeded :-)
I will remove some more.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/7] Support of Flow Director in HNS3 Ethernet Driver for HiP08 Rev2 SoC
From: David Miller @ 2018-10-02 5:58 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20181001114647.15504-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 1 Oct 2018 12:46:40 +0100
> This patch-set adds the support of FD(Flow Director) in the HNS3 PF driver
> for HiP08 Rev2(0x21) SoC of Hisilicon. FD can be used in filtering the flows
> and deciding to drop the flow or forward it to paricular queue.
>
> Configuration consists of rules with input keys and actions. The rules are
> stored in TCAM.
Series applied.
^ permalink raw reply
* Re: [PATCH net] r8169: Enable MSI-X on RTL8106e
From: David Miller @ 2018-10-02 5:51 UTC (permalink / raw)
To: jian-hong
Cc: hkallweit1, nic_swsd, netdev, linux-kernel, kai.heng.feng, linux
In-Reply-To: <20180927040948.11891-1-jian-hong@endlessm.com>
From: Jian-Hong Pan <jian-hong@endlessm.com>
Date: Thu, 27 Sep 2018 12:09:48 +0800
> However, there is a commit which resolves the drivers getting nothing in
> PCI BAR=4 after system resumes. It is 04cb3ae895d7 "PCI: Reprogram
> bridge prefetch registers on resume" by Daniel Drake.
I don't see this upstream yet.
^ permalink raw reply
* Re: [PATCH net-next] net: nixge: Address compiler warnings when building for i386
From: David Miller @ 2018-10-02 5:49 UTC (permalink / raw)
To: mdf
Cc: linux-kernel, netdev, keescook, moritz.fischer, f.fainelli,
alex.williams, arnd
In-Reply-To: <20180927194851.3042-1-mdf@kernel.org>
From: Moritz Fischer <mdf@kernel.org>
Date: Thu, 27 Sep 2018 12:48:51 -0700
> Address compiler warning reported by kbuild autobuilders
> when building for i386 as a result of dma_addr_t size on
> different architectures.
>
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
>
> Fixes: 7e8d5755be0e ("net: nixge: Add support for 64-bit platforms")
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: start receiver buffer autotuning sooner
From: Yuchung Cheng @ 2018-10-01 23:07 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, netdev, Neal Cardwell, Wei Wang,
Soheil Hassas Yeganeh
In-Reply-To: <20181001.154600.398152617755232823.davem@davemloft.net>
On Mon, Oct 1, 2018 at 3:46 PM, David Miller <davem@davemloft.net> wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Mon, 1 Oct 2018 15:42:32 -0700
>
>> Previously receiver buffer auto-tuning starts after receiving
>> one advertised window amount of data. After the initial receiver
>> buffer was raised by patch a337531b942b ("tcp: up initial rmem to
>> 128KB and SYN rwin to around 64KB"), the reciver buffer may take
>> too long to start raising. To address this issue, this patch lowers
>> the initial bytes expected to receive roughly the expected sender's
>> initial window.
>>
>> Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>> Signed-off-by: Wei Wang <weiwan@google.com>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
>
> Applied, sorry for applying v1 instead of v2 the the rmem increasing patch.
> :-/
No problem thanks for the fast response!
^ permalink raw reply
* Re: [pull request][net-next 00/13] Mellanox, mlx5e updates 2018-10-01
From: David Miller @ 2018-10-01 22:49 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20181001185701.2944-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 1 Oct 2018 11:56:48 -0700
> The following pull request includes updates to mlx5e ethernet netdevice
> driver, for more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH] Revert "openvswitch: Fix template leak in error cases."
From: Joe Stringer @ 2018-10-01 22:46 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netfilter-devel, netdev, ovs dev, pravin shelar
In-Reply-To: <20180928175534.13590-1-fbl@redhat.com>
On Fri, 28 Sep 2018 at 10:55, Flavio Leitner <fbl@redhat.com> wrote:
>
> This reverts commit 90c7afc96cbbd77f44094b5b651261968e97de67.
>
> When the commit was merged, the code used nf_ct_put() to free
> the entry, but later on commit 76644232e612 ("openvswitch: Free
> tmpl with tmpl_free.") replaced that with nf_ct_tmpl_free which
> is a more appropriate. Now the original problem is removed.
>
> Then 44d6e2f27328 ("net: Replace NF_CT_ASSERT() with WARN_ON().")
> replaced a debug assert with a WARN_ON() which is trigged now.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
> ---
Thanks for the cleanup.
Acked-by: Joe Stringer <joe@ovn.org>
^ permalink raw reply
* Re: [PATCH net-next] tcp: start receiver buffer autotuning sooner
From: David Miller @ 2018-10-01 22:46 UTC (permalink / raw)
To: ycheng; +Cc: edumazet, netdev, ncardwell, weiwan, soheil
In-Reply-To: <20181001224232.39939-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 1 Oct 2018 15:42:32 -0700
> Previously receiver buffer auto-tuning starts after receiving
> one advertised window amount of data. After the initial receiver
> buffer was raised by patch a337531b942b ("tcp: up initial rmem to
> 128KB and SYN rwin to around 64KB"), the reciver buffer may take
> too long to start raising. To address this issue, this patch lowers
> the initial bytes expected to receive roughly the expected sender's
> initial window.
>
> Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Applied, sorry for applying v1 instead of v2 the the rmem increasing patch.
:-/
^ permalink raw reply
* Re: [Potential Spoof] Re: [PATCH v2] net/ncsi: Add NCSI OEM command support
From: Vijay Khemka @ 2018-10-01 22:45 UTC (permalink / raw)
To: Justin . Lee1 @ Dell . com, joel @ jms . id . au,
linux-aspeed @ lists . ozlabs . org,
openbmc @ lists . ozlabs . org, Sai Dasari,
netdev @ vger . kernel . org, christian @ cmd . nu,
Samuel Mendoza-Jonas
On 9/28/18, 6:21 PM, "Linux-aspeed on behalf of Vijay Khemka" <linux-aspeed-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of vijaykhemka@fb.com> wrote:
> On 9/28/18, 6:07 PM, "Vijay Khemka" <vijaykhemka@fb.com> wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with its
> handlers.
>
> ncsi_cmd_handler_oem: This is a generic command request handler for OEM
> commands
> ncsi_rsp_handler_oem: This is a generic response handler for OEM commands
This is a generic patch for OEM command handling, There will be another patch
following this to handle specific OEM commands for each vendor. Currently I have
defined 2 vendor/manufacturer id below in internal.h, more can be added here for
other vendors. I have not defined ncsi_rsp_oem_handler in this patch as they are
NULL, but there will be a defined handlers for each vendor in next patch.
Sam, Joel, Justin, please review this patch. I have 2 more patch coming for Broadcom and Mellanox.
^ 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