* [PATCH] xfrm: do not check x->km.state
From: roy.qing.li @ 2012-12-13 9:06 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
do not check x->km.state, it will be checked by succedent
xfrm_state_check_expire()
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/xfrm6_input.c | 1 -
net/xfrm/xfrm_input.c | 4 ----
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index f8c3cf8..de4babd 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -108,7 +108,6 @@ int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
spin_lock(&x->lock);
if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
- likely(x->km.state == XFRM_STATE_VALID) &&
!xfrm_state_check_expire(x)) {
spin_unlock(&x->lock);
if (x->type->input(x, skb) > 0) {
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index ab2bb42..a8fbb09 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -163,10 +163,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
skb->sp->xvec[skb->sp->len++] = x;
spin_lock(&x->lock);
- if (unlikely(x->km.state != XFRM_STATE_VALID)) {
- XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEINVALID);
- goto drop_unlock;
- }
if ((x->encap ? x->encap->encap_type : 0) != encap_type) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMISMATCH);
--
1.7.5.4
^ permalink raw reply related
* [PATCH iproute2 v2] ip: use rtnelink to manage mroute
From: Nicolas Dichtel @ 2012-12-13 9:16 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <20121212102617.0a3249e4@nehalam.linuxnetplumber.net>
mroute was using /proc/net/ip_mr_[vif|cache] to display mroute entries. Hence,
only RT_TABLE_DEFAULT was displayed and only IPv4.
With rtnetlink, it is possible to display all tables for IPv4 and IPv6. The output
format is kept. Also, like before the patch, statistics are displayed when user specify
the '-s' argument.
The patch also adds the support of 'ip monitor mroute', which is now possible.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: fix compilation warnings on 64bits arch
ip/ip_common.h | 3 +
ip/ipmonitor.c | 35 ++++++-
ip/ipmroute.c | 297 ++++++++++++++++++++++++++++++++++-----------------------
3 files changed, 214 insertions(+), 121 deletions(-)
create mode 100644 ip/ipmonitor.
diff --git a/ip/ip_common.h b/ip/ip_common.h
index a394669..de56810 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -16,11 +16,14 @@ extern int ipaddr_list_link(int argc, char **argv);
extern int iproute_monitor(int argc, char **argv);
extern void iplink_usage(void) __attribute__((noreturn));
extern void iproute_reset_filter(void);
+extern void ipmroute_reset_filter(void);
extern void ipaddr_reset_filter(int);
extern void ipneigh_reset_filter(void);
extern void ipntable_reset_filter(void);
extern int print_route(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
+extern int print_mroute(const struct sockaddr_nl *who,
+ struct nlmsghdr *n, void *arg);
extern int print_prefix(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
extern int print_rule(const struct sockaddr_nl *who,
diff --git a/ip/ipmonitor. b/ip/ipmonitor.
new file mode 100644
index 0000000..e69de29
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index d971623..09a339c 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -43,10 +43,26 @@ int accept_msg(const struct sockaddr_nl *who,
print_timestamp(fp);
if (n->nlmsg_type == RTM_NEWROUTE || n->nlmsg_type == RTM_DELROUTE) {
- if (prefix_banner)
- fprintf(fp, "[ROUTE]");
- print_route(who, n, arg);
- return 0;
+ struct rtmsg *r = NLMSG_DATA(n);
+ int len = n->nlmsg_len - NLMSG_LENGTH(sizeof(*r));
+
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
+ }
+
+ if (r->rtm_family == RTNL_FAMILY_IPMR ||
+ r->rtm_family == RTNL_FAMILY_IP6MR) {
+ if (prefix_banner)
+ fprintf(fp, "[MROUTE]");
+ print_mroute(who, n, arg);
+ return 0;
+ } else {
+ if (prefix_banner)
+ fprintf(fp, "[ROUTE]");
+ print_route(who, n, arg);
+ return 0;
+ }
}
if (n->nlmsg_type == RTM_NEWLINK || n->nlmsg_type == RTM_DELLINK) {
ll_remember_index(who, n, NULL);
@@ -123,6 +139,7 @@ int do_ipmonitor(int argc, char **argv)
int llink=0;
int laddr=0;
int lroute=0;
+ int lmroute=0;
int lprefix=0;
int lneigh=0;
int lnetconf=0;
@@ -130,6 +147,7 @@ int do_ipmonitor(int argc, char **argv)
rtnl_close(&rth);
ipaddr_reset_filter(1);
iproute_reset_filter();
+ ipmroute_reset_filter();
ipneigh_reset_filter();
while (argc > 0) {
@@ -145,6 +163,9 @@ int do_ipmonitor(int argc, char **argv)
} else if (matches(*argv, "route") == 0) {
lroute=1;
groups = 0;
+ } else if (matches(*argv, "mroute") == 0) {
+ lmroute=1;
+ groups = 0;
} else if (matches(*argv, "prefix") == 0) {
lprefix=1;
groups = 0;
@@ -180,6 +201,12 @@ int do_ipmonitor(int argc, char **argv)
if (!preferred_family || preferred_family == AF_INET6)
groups |= nl_mgrp(RTNLGRP_IPV6_ROUTE);
}
+ if (lmroute) {
+ if (!preferred_family || preferred_family == AF_INET)
+ groups |= nl_mgrp(RTNLGRP_IPV4_MROUTE);
+ if (!preferred_family || preferred_family == AF_INET6)
+ groups |= nl_mgrp(RTNLGRP_IPV6_MROUTE);
+ }
if (lprefix) {
if (!preferred_family || preferred_family == AF_INET6)
groups |= nl_mgrp(RTNLGRP_IPV6_PREFIX);
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 945727d..defcfc5 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -15,6 +15,7 @@
#include <unistd.h>
#include <syslog.h>
#include <fcntl.h>
+#include <inttypes.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <netinet/in.h>
@@ -26,167 +27,229 @@
#include <linux/if_arp.h>
#include <linux/sockios.h>
+#include <rt_names.h>
#include "utils.h"
-
-char filter_dev[16];
-int filter_family;
+#include "ip_common.h"
static void usage(void) __attribute__((noreturn));
static void usage(void)
{
- fprintf(stderr, "Usage: ip mroute show [ PREFIX ] [ from PREFIX ] [ iif DEVICE ]\n");
+ fprintf(stderr, "Usage: ip mroute show [ [ to ] PREFIX ] [ from PREFIX ] [ iif DEVICE ]\n");
#if 0
fprintf(stderr, "Usage: ip mroute [ add | del ] DESTINATION from SOURCE [ iif DEVICE ] [ oif DEVICE ]\n");
#endif
exit(-1);
}
-static char *viftable[32];
-
struct rtfilter
{
+ int tb;
+ int af;
+ int iif;
inet_prefix mdst;
inet_prefix msrc;
} filter;
-static void read_viftable(void)
+int print_mroute(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
- char buf[256];
- FILE *fp = fopen("/proc/net/ip_mr_vif", "r");
-
- if (!fp)
- return;
-
- if (!fgets(buf, sizeof(buf), fp)) {
- fclose(fp);
- return;
+ FILE *fp = (FILE*)arg;
+ struct rtmsg *r = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr * tb[RTA_MAX+1];
+ char abuf[256];
+ char obuf[256];
+ SPRINT_BUF(b1);
+ __u32 table;
+ int iif = 0;
+ int family;
+
+ if ((n->nlmsg_type != RTM_NEWROUTE &&
+ n->nlmsg_type != RTM_DELROUTE) ||
+ !(n->nlmsg_flags & NLM_F_MULTI)) {
+ fprintf(stderr, "Not a multicast route: %08x %08x %08x\n",
+ n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ return 0;
}
- while (fgets(buf, sizeof(buf), fp)) {
- int vifi;
- char dev[256];
-
- if (sscanf(buf, "%d%s", &vifi, dev) < 2)
- continue;
-
- if (vifi<0 || vifi>31)
- continue;
-
- viftable[vifi] = strdup(dev);
+ len -= NLMSG_LENGTH(sizeof(*r));
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
}
- fclose(fp);
-}
-
-static void read_mroute_list(FILE *ofp)
-{
- char buf[256];
- FILE *fp = fopen("/proc/net/ip_mr_cache", "r");
-
- if (!fp)
- return;
-
- if (!fgets(buf, sizeof(buf), fp)) {
- fclose(fp);
- return;
+ if (r->rtm_type != RTN_MULTICAST) {
+ fprintf(stderr, "Not a multicast route (type: %s)\n",
+ rtnl_rtntype_n2a(r->rtm_type, b1, sizeof(b1)));
+ return 0;
}
- while (fgets(buf, sizeof(buf), fp)) {
- inet_prefix maddr, msrc;
- unsigned pkts, b, w;
- int vifi;
- char oiflist[256];
- char sbuf[256];
- char mbuf[256];
- char obuf[256];
-
- oiflist[0] = 0;
- if (sscanf(buf, "%x%x%d%u%u%u %[^\n]",
- maddr.data, msrc.data, &vifi,
- &pkts, &b, &w, oiflist) < 6)
- continue;
-
- if (vifi!=-1 && (vifi < 0 || vifi>31))
- continue;
-
- if (filter_dev[0] && (vifi<0 || strcmp(filter_dev, viftable[vifi])))
- continue;
- if (filter.mdst.family && inet_addr_match(&maddr, &filter.mdst, filter.mdst.bitlen))
- continue;
- if (filter.msrc.family && inet_addr_match(&msrc, &filter.msrc, filter.msrc.bitlen))
- continue;
-
- snprintf(obuf, sizeof(obuf), "(%s, %s)",
- format_host(AF_INET, 4, &msrc.data[0], sbuf, sizeof(sbuf)),
- format_host(AF_INET, 4, &maddr.data[0], mbuf, sizeof(mbuf)));
-
- fprintf(ofp, "%-32s Iif: ", obuf);
-
- if (vifi == -1)
- fprintf(ofp, "unresolved ");
- else
- fprintf(ofp, "%-10s ", viftable[vifi]);
-
- if (oiflist[0]) {
- char *next = NULL;
- char *p = oiflist;
- int ovifi, ottl;
-
- fprintf(ofp, "Oifs: ");
-
- while (p) {
- next = strchr(p, ' ');
- if (next) {
- *next = 0;
- next++;
- }
- if (sscanf(p, "%d:%d", &ovifi, &ottl)<2) {
- p = next;
- continue;
- }
- p = next;
-
- fprintf(ofp, "%s", viftable[ovifi]);
- if (ottl>1)
- fprintf(ofp, "(ttl %d) ", ovifi);
- else
- fprintf(ofp, " ");
+ parse_rtattr(tb, RTA_MAX, RTM_RTA(r), len);
+ table = rtm_get_table(r, tb);
+
+ if (filter.tb > 0 && filter.tb != table)
+ return 0;
+
+ if (tb[RTA_IIF])
+ iif = *(int*)RTA_DATA(tb[RTA_IIF]);
+ if (filter.iif && filter.iif != iif)
+ return 0;
+
+ if (filter.af && filter.af != r->rtm_family)
+ return 0;
+
+ if (tb[RTA_DST] &&
+ filter.mdst.bitlen > 0 &&
+ inet_addr_match(RTA_DATA(tb[RTA_DST]), &filter.mdst, filter.mdst.bitlen))
+ return 0;
+
+ if (tb[RTA_SRC] &&
+ filter.msrc.bitlen > 0 &&
+ inet_addr_match(RTA_DATA(tb[RTA_SRC]), &filter.msrc, filter.msrc.bitlen))
+ return 0;
+
+ family = r->rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
+
+ if (n->nlmsg_type == RTM_DELROUTE)
+ fprintf(fp, "Deleted ");
+
+ if (tb[RTA_SRC])
+ len = snprintf(obuf, sizeof(obuf),
+ "(%s, ", rt_addr_n2a(family,
+ RTA_PAYLOAD(tb[RTA_SRC]),
+ RTA_DATA(tb[RTA_SRC]),
+ abuf, sizeof(abuf)));
+ else
+ len = sprintf(obuf, "(unknown, ");
+ if (tb[RTA_DST])
+ snprintf(obuf + len, sizeof(obuf) - len,
+ "%s)", rt_addr_n2a(family, RTA_PAYLOAD(tb[RTA_DST]),
+ RTA_DATA(tb[RTA_DST]),
+ abuf, sizeof(abuf)));
+ else
+ snprintf(obuf + len, sizeof(obuf) - len, "unknown) ");
+
+ fprintf(fp, "%-32s Iif: ", obuf);
+ if (iif)
+ fprintf(fp, "%-10s ", ll_index_to_name(iif));
+ else
+ fprintf(fp, "unresolved ");
+
+ if (tb[RTA_MULTIPATH]) {
+ struct rtnexthop *nh = RTA_DATA(tb[RTA_MULTIPATH]);
+ int first = 1;
+
+ len = RTA_PAYLOAD(tb[RTA_MULTIPATH]);
+
+ for (;;) {
+ if (len < sizeof(*nh))
+ break;
+ if (nh->rtnh_len > len)
+ break;
+
+ if (first) {
+ fprintf(fp, "Oifs: ");
+ first = 0;
}
+ fprintf(fp, "%s", ll_index_to_name(nh->rtnh_ifindex));
+ if (nh->rtnh_hops > 1)
+ fprintf(fp, "(ttl %d) ", nh->rtnh_hops);
+ else
+ fprintf(fp, " ");
+ len -= NLMSG_ALIGN(nh->rtnh_len);
+ nh = RTNH_NEXT(nh);
}
-
- if (show_stats && b) {
- fprintf(ofp, "%s %u packets, %u bytes", _SL_, pkts, b);
- if (w)
- fprintf(ofp, ", %u arrived on wrong iif.", w);
- }
- fprintf(ofp, "\n");
}
- fclose(fp);
+ if (show_stats && tb[RTA_MFC_STATS]) {
+ struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
+
+ fprintf(fp, "%s %"PRIu64" packets, %"PRIu64" bytes", _SL_,
+ (uint64_t)mfcs->mfcs_packets,
+ (uint64_t)mfcs->mfcs_bytes);
+ if (mfcs->mfcs_wrong_if)
+ fprintf(fp, ", %"PRIu64" arrived on wrong iif.",
+ (uint64_t)mfcs->mfcs_wrong_if);
+ }
+ fprintf(fp, "\n");
+ fflush(fp);
+ return 0;
}
+void ipmroute_reset_filter(void)
+{
+ memset(&filter, 0, sizeof(filter));
+ filter.mdst.bitlen = -1;
+ filter.msrc.bitlen = -1;
+}
static int mroute_list(int argc, char **argv)
{
+ char *id = NULL;
+ int family;
+
+ ipmroute_reset_filter();
+ if (preferred_family == AF_UNSPEC)
+ family = AF_INET;
+ else
+ family = AF_INET6;
+ if (family == AF_INET) {
+ filter.af = RTNL_FAMILY_IPMR;
+ filter.tb = RT_TABLE_DEFAULT; /* for backward compatibility */
+ } else
+ filter.af = RTNL_FAMILY_IP6MR;
+
while (argc > 0) {
- if (strcmp(*argv, "iif") == 0) {
+ if (matches(*argv, "table") == 0) {
+ __u32 tid;
NEXT_ARG();
- strncpy(filter_dev, *argv, sizeof(filter_dev)-1);
+ if (rtnl_rttable_a2n(&tid, *argv)) {
+ if (strcmp(*argv, "all") == 0) {
+ filter.tb = 0;
+ } else if (strcmp(*argv, "help") == 0) {
+ usage();
+ } else {
+ invarg("table id value is invalid\n", *argv);
+ }
+ } else
+ filter.tb = tid;
+ } else if (strcmp(*argv, "iif") == 0) {
+ NEXT_ARG();
+ id = *argv;
} else if (matches(*argv, "from") == 0) {
NEXT_ARG();
- get_prefix(&filter.msrc, *argv, AF_INET);
+ get_prefix(&filter.msrc, *argv, family);
} else {
if (strcmp(*argv, "to") == 0) {
NEXT_ARG();
}
if (matches(*argv, "help") == 0)
usage();
- get_prefix(&filter.mdst, *argv, AF_INET);
+ get_prefix(&filter.mdst, *argv, family);
}
- argv++; argc--;
+ argc--; argv++;
}
- read_viftable();
- read_mroute_list(stdout);
- return 0;
+ ll_init_map(&rth);
+
+ if (id) {
+ int idx;
+
+ if ((idx = ll_name_to_index(id)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", id);
+ return -1;
+ }
+ filter.iif = idx;
+ }
+
+ if (rtnl_wilddump_request(&rth, filter.af, RTM_GETROUTE) < 0) {
+ perror("Cannot send dump request");
+ return 1;
+ }
+
+ if (rtnl_dump_filter(&rth, print_mroute, stdout) < 0) {
+ fprintf(stderr, "Dump terminated\n");
+ exit(1);
+ }
+
+ exit(0);
}
int do_multiroute(int argc, char **argv)
--
1.8.0.1
^ permalink raw reply related
* [PATCH] return the devices dummyX to the initial network namespace after container closure.
From: V. Lavrov @ 2012-12-13 9:13 UTC (permalink / raw)
To: netdev
If container has a network device dummyX (with lxc.network.type = phys), then it disappears from the system after you close the container.
The patch returns the device dummyX to the initial network namespace after container is closed.
Signed-off-by: Vitaly Lavrov <lve@guap.ru>
---
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index bab0158..efa990c 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -160,6 +160,41 @@ static struct rtnl_link_ops dummy_link_ops __read_mostly = {
module_param(numdummies, int, 0);
MODULE_PARM_DESC(numdummies, "Number of dummy pseudo devices");
+
+static void __net_exit dummy_net_exit(struct net *net) {
+ struct net_device *dev, *aux;
+ int err;
+
+ if(net == &init_net) return;
+
+ rtnl_lock();
+ for_each_netdev_safe(net, dev, aux) {
+ if(dev->rtnl_link_ops == &dummy_link_ops) {
+ err = dev_change_net_namespace(dev, &init_net, dev->name);
+ if(err) {
+ char fb_name[IFNAMSIZ];
+ printk (KERN_INFO "%s: dev_change_net_namespace(init_net,%s) err: %d\n",
+ __func__,dev->name,err);
+ snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex);
+ err = dev_change_net_namespace(dev, &init_net, dev->name);
+ if(err)
+ printk (KERN_INFO "%s: dev_change_net_namespace(%s,init_net,%s) err: %d\n",
+ __func__,dev->name,fb_name,err);
+ else
+ printk (KERN_INFO "%s: %s rename to %s\n",
+ __func__,dev->name,fb_name);
+
+ }
+ }
+ }
+ rtnl_unlock();
+}
+
+static struct pernet_operations __net_initdata dummy_net_ops = {
+ .exit = dummy_net_exit,
+};
+
+
static int __init dummy_init_one(void)
{
struct net_device *dev_dummy;
@@ -184,6 +219,10 @@ static int __init dummy_init_module(void)
{
int i, err = 0;
+ err = register_pernet_device(&dummy_net_ops);
+ if(err)
+ return err;
+
rtnl_lock();
err = __rtnl_link_register(&dummy_link_ops);
@@ -191,8 +230,10 @@ static int __init dummy_init_module(void)
err = dummy_init_one();
cond_resched();
}
- if (err < 0)
+ if (err < 0) {
__rtnl_link_unregister(&dummy_link_ops);
+ unregister_pernet_device(&dummy_net_ops);
+ }
rtnl_unlock();
return err;
@@ -201,6 +242,7 @@ static int __init dummy_init_module(void)
static void __exit dummy_cleanup_module(void)
{
rtnl_link_unregister(&dummy_link_ops);
+ unregister_pernet_device(&dummy_net_ops);
}
module_init(dummy_init_module);
--
^ permalink raw reply related
* Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: Steffen Klassert @ 2012-12-13 10:14 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1355387152-9963-1-git-send-email-roy.qing.li@gmail.com>
On Thu, Dec 13, 2012 at 04:25:52PM +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> If setkey sets both bh and bs as 1024, and the total send and receive package
> size is 1024, then if next package size is too large, this package should be
> discard.
>
> Example, first package size is 1000, send success, then the second package
> is 500, 1000+500 is larger than 1024, so the second package should be discard.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/xfrm/xfrm_input.c | 6 +++---
> net/xfrm/xfrm_output.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index ab2bb42..d0de8f3 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -178,6 +178,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> goto drop_unlock;
> }
>
> + x->curlft.bytes += skb->len;
> + x->curlft.packets++;
> +
This is a bit critical on input. We should only increment these values
if the integrity check on this packet was successfull. Otherwise someone
could spam us with invalid packets and trigger a state expiry.
If a synchronous crypto algorithm is used, we send at most one packet too
much. The maximal byte count was not yet reached and RFC 2401 says not
much on how to handle the packet that reaches the maximal byte count,
so this is probaply ok.
But if an asynchronous crypto algorithm is used, we can send a lot
of packets too much. So we should probaply add a second expiry check
after resume from asynchronous crypto. We do this already with the replay
check.
^ permalink raw reply
* Re: [PATCH] xfrm: do not check x->km.state
From: Steffen Klassert @ 2012-12-13 10:19 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1355389560-7705-1-git-send-email-roy.qing.li@gmail.com>
On Thu, Dec 13, 2012 at 05:06:00PM +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> do not check x->km.state, it will be checked by succedent
> xfrm_state_check_expire()
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv6/xfrm6_input.c | 1 -
> net/xfrm/xfrm_input.c | 4 ----
> 2 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
> index f8c3cf8..de4babd 100644
> --- a/net/ipv6/xfrm6_input.c
> +++ b/net/ipv6/xfrm6_input.c
> @@ -108,7 +108,6 @@ int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
> spin_lock(&x->lock);
>
> if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
> - likely(x->km.state == XFRM_STATE_VALID) &&
> !xfrm_state_check_expire(x)) {
> spin_unlock(&x->lock);
> if (x->type->input(x, skb) > 0) {
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index ab2bb42..a8fbb09 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -163,10 +163,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> skb->sp->xvec[skb->sp->len++] = x;
>
> spin_lock(&x->lock);
> - if (unlikely(x->km.state != XFRM_STATE_VALID)) {
> - XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEINVALID);
> - goto drop_unlock;
> - }
This would remove the only place where the LINUX_MIB_XFRMINSTATEINVALID
statistics counter is incremented. I think it would be better to ensure
a valid state before we call xfrm_state_check_expire(). This would make
the statistics more accurate and we can remove the x->km.state check
from xfrm_state_check_expire().
^ permalink raw reply
* Re: netconsole fun
From: Cong Wang @ 2012-12-13 10:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <1355345957.2687.18.camel@thor>
On Wed, 12 Dec 2012 at 20:59 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
>
> Just wondering if you think something like the patch below is
> suitable/acceptable for insulating netconsole from inconsistent device
> name scenarios without changing the existing semantics. The basic idea
> is to allow an ethernet MAC address in the <dev> field of the
> netconsole= options, and if a MAC address was specified rather than a
> device name, to do the dev lookup from the MAC address instead.
>
> This doesn't extend to, but also doesn't interfere with, the dynamic
> config of netconsole via configfs.
>
> Would you mind reviewing it?
>
This is a good idea. Just that you need to complete the configfs
interface too.
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-13 10:58 UTC (permalink / raw)
To: Yury Stankevich; +Cc: netdev@vger.kernel.org, pablo
In-Reply-To: <50C4821D.5090206@gmail.com>
Yury,
This appears to be an ABI breakage on iptables/netfilter side.
I will look at it (and hopefully fix it) over the weekend.
cheers,
jamal
On 12-12-09 07:20 AM, Yury Stankevich wrote:
> Hello,
>
> i not sure this is correct list, please advise if not.
>
> i'm trying to use ipt action, and got a problem:
>
> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK --restore-mark action mirred egress redirect dev ifb0
> -> bad action type ipt
>
> from strace:
> open("/usr/lib/tc//m_gact.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> write(2, "bad action type ipt\n", 20bad action type ipt
>
> well. i'm trying to use xt:
> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action xt -j CONNMARK --restore-mark action mirred egress redirect dev ifb0
> xt: unrecognized option '--restore-mark'
>
> from strace:
> open("/lib/xtables/libxt_CONNMARK.so", O_RDONLY) = 4
> read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\6\0\0004\0\0\0"...,
> 512) = 512
> fstat64(4, {st_mode=S_IFREG|0644, st_size=9756, ...}) = 0
> mmap2(NULL, 12548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0)
> = 0xf76f3000
> mmap2(0xf76f5000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xf76f5000
> close(4) = 0
> mprotect(0xf76f5000, 4096, PROT_READ) = 0
> socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> lstat64("/proc/net/ip_tables_names", {st_mode=S_IFREG|0440, st_size=0,
> ...}) = 0
> statfs64("/proc/net/ip_tables_names", 84, {f_type="PROC_SUPER_MAGIC",
> f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> getsockopt(4, SOL_IP, 0x43 /* IP_??? */,
> "CONNMARK\0\367\f\300\0\0\0po\367l8p\367\364/p\367:}\302\1", [30]) = 0
> close(4) = 0
> write(2, "xt: unrecognized option '--resto"..., 41xt: unrecognized
> option '--restore-mark'
>
> so... i make something wrong or this is a bug ?
>
> ps: 3.6.8 kernel 64 bit kernel with 32 bit userspace, iproute 20121001
> from debian-experimental,
> module act_ipt is loaded.
> pps: please, cc me in reply.
>
>
^ permalink raw reply
* Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
From: Tomi Valkeinen @ 2012-12-13 11:07 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, davem, linux-arm-kernel, linux-omap, b-cousson, paul,
richardcochran
In-Reply-To: <1354012034-31686-1-git-send-email-mugunthanvnm@ti.com>
Hi,
On 2012-11-27 12:27, Mugunthan V N wrote:
> CC drivers/net/ethernet/ti/cpts.o
> drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory
> compilation terminated.
> make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> make[3]: *** [drivers/net/ethernet/ti] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
>
> fix for build break as the header file is removed from plat-omap as part of
> the below patch
linux-next still has this build problem, I guess this patch is lingering
somewhere. Somewhat annoying, as the driver is enabled by default. (btw,
why is it "default y"?)
Tomi
^ permalink raw reply
* [PATCH v2] ipv6: Change skb->data before using icmpv6_notify() to propagate redirect
From: Duan Jiong @ 2012-12-13 11:21 UTC (permalink / raw)
To: davem; +Cc: Steffen Klassert, netdev
In function ndisc_redirect_rcv(), the skb->data points to the transport
header, but function icmpv6_notify() need the skb->data points to the
inner IP packet. So before using icmpv6_notify() to propagate redirect,
change skb->data to point the inner IP packet that triggered the sending
of the Redirect, and introduce struct rd_msg to make it easy.
Many thanks to Steffen Klassert.
Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
---
include/net/ndisc.h | 7 +++++++
net/ipv6/ndisc.c | 22 ++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 980d263..6b305d7 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -78,6 +78,13 @@ struct ra_msg {
__be32 retrans_timer;
};
+struct rd_msg {
+ struct icmp6hdr icmph;
+ struct in6_addr target;
+ struct in6_addr dest;
+ __u8 opt[0];
+};
+
struct nd_opt_hdr {
__u8 nd_opt_type;
__u8 nd_opt_len;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 2edce30..03deabc 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1333,6 +1333,12 @@ out:
static void ndisc_redirect_rcv(struct sk_buff *skb)
{
+ u8 *hdr;
+ struct ndisc_options ndopts;
+ struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
+ u32 ndoptlen = skb->tail - (skb->transport_header +
+ offsetof(struct rd_msg, opt));
+
#ifdef CONFIG_IPV6_NDISC_NODETYPE
switch (skb->ndisc_nodetype) {
case NDISC_NODETYPE_HOST:
@@ -1349,6 +1355,22 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
return;
}
+ if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) {
+ ND_PRINTK(2, warn,
+ "Redirect: invalid ND options\n");
+ return;
+ }
+
+ if (!ndopts.nd_opts_rh) {
+ return;
+ }
+
+ hdr = (u8 *)ndopts.nd_opts_rh;
+ hdr += 8;
+ if(!pskb_pull(skb, hdr - skb_transport_header(skb))) {
+ return;
+ }
+
icmpv6_notify(skb, NDISC_REDIRECT, 0, 0);
}
--
1.7.1
^ permalink raw reply related
* Re: netconsole fun
From: Neil Horman @ 2012-12-13 12:36 UTC (permalink / raw)
To: Peter Hurley; +Cc: Cong Wang, netdev
In-Reply-To: <1355345957.2687.18.camel@thor>
On Wed, Dec 12, 2012 at 03:59:17PM -0500, Peter Hurley wrote:
> On Tue, 2012-12-11 at 11:45 -0500, Neil Horman wrote:
> > On Tue, Dec 11, 2012 at 10:16:51AM -0500, Peter Hurley wrote:
> > > On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> > > > On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > > > > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > > > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > > > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > > > > recommended method of running netconsole on a machine that has a slaved
> > > > > > > device?
> > > > > > >
> > > > > >
> > > > > > Yes, running it on the master device instead.
> > > > >
> > > > > Thanks for the suggestion, but:
> > > > >
> > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.10.99/br0,30000@192.168.10.100/xx:xx:xx:xx:xx:xx
> > > > > ...
> > > > > [ 5.289869] netpoll: netconsole: local port 6665
> > > > > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > > > > [ 5.289892] netpoll: netconsole: interface 'br0'
> > > > > [ 5.289898] netpoll: netconsole: remote port 30000
> > > > > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > > > > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > > > > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > > > > [ 5.289929] netconsole: cleaning up
> > > > > ...
> > > > > [ 9.392291] Bridge firewalling registered
> > > > > [ 9.396805] device eth1 entered promiscuous mode
> > > > > [ 9.418350] eth1: setting full-duplex.
> > > > > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > > > > [ 9.423354] br0: port 1(eth1) entered forwarding state
> > > > >
> > > > >
> > > > > Is there a way to control or associate network device names prior to
> > > > > udev renaming?
> > > > >
> > > > That looks like a systemd problem (or more specifically a boot dependency
> > > > problem). You need to modify your netconsole unit/service file to start after
> > > > all your networking is up. NetworkManager provides a dummy service file for
> > > > this purpose, called networkmanager-wait-online.service
> > >
> > > Ok. So with a single physical network interface that will be bridged,
> > > netconsole cannot used for kernel boot messages.
> > >
> > > With a machine with multiple nics, is there a way to control device
> > > naming so that the interface name to be used by netconsole specified on
> > > the boot command line will actually corresponding to the intended
> > > device. For example,
> > >
> > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.1.123/eth0,30000@192.168.1.139/xx:xx:xx:xx:xx:xx
> > > ....
> > > [ 4.092184] 3c59x: Donald Becker and others.
> > > [ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
> > > [ 4.094035] tg3.c:v3.125 (September 26, 2012)
> > > ....
> > > [ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > > [ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > [ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > > [ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
> > >
> > > This is attaching netconsole to the wrong device because bus
> > > enumeration, and therefore load order, is not consistent from boot to
> > > boot.
> > >
> > No, theres no way to do that. As you note device ennumeration isn't consistent
> > accross boots, thats why udev creates rules to rename devices based on immutable
> > (or semi-immutable) data, like mac addresses, or pci bus locations). Once that
> > happens, you'll have consistent names for your interfaces, and that work will be
> > guaranteed to be done after networkmanager has finished opening all the
> > interfaces that it needs (hence my suggestion to make netconsole service
> > dependent on networkmanager service startup completing).
>
> Just wondering if you think something like the patch below is
> suitable/acceptable for insulating netconsole from inconsistent device
> name scenarios without changing the existing semantics. The basic idea
> is to allow an ethernet MAC address in the <dev> field of the
> netconsole= options, and if a MAC address was specified rather than a
> device name, to do the dev lookup from the MAC address instead.
>
> This doesn't extend to, but also doesn't interfere with, the dynamic
> config of netconsole via configfs.
>
> Would you mind reviewing it?
>
> Regards,
> Peter
>
This looks like a pretty good idea to me. That said, something occured to me
when you wrote your summary above. Have you looked at the netconsole service
scripts that most distros provide in their packaging? I'm almost positive Red
Hat/Fedora (and also like Suse and Ubuntu), already implement this functionality
from user space. Basically, instead of people just modprobing netconsole, they
create a service script that parses a config file that has contains all the
options needed to load the netconsole module, and it has the intellegence to see
if you specified a mac address rather than a device. If you did that it finds
the corresponding device mac address and uses that as the device. I'm sorry, I
don't know why I didn't think of that before. Check that out though, that will
likey give you exactly what you need
Neil
P.S. Actually looking at it, I think it does one better, it lets you specify the
destinaition netconsole address, and then dynamically looks up the routing table
entry that gets you there, and uses the output device specified in the routing
table.
http://www.cyberciti.biz/tips/linux-netconsole-log-management-tutorial.html
^ permalink raw reply
* Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
From: Richard Cochran @ 2012-12-13 13:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mugunthan V N, netdev, davem, linux-arm-kernel, linux-omap,
b-cousson, paul
In-Reply-To: <50C9B6F9.9020300@iki.fi>
On Thu, Dec 13, 2012 at 01:07:37PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2012-11-27 12:27, Mugunthan V N wrote:
> > CC drivers/net/ethernet/ti/cpts.o
> > drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory
> > compilation terminated.
> > make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> > make[3]: *** [drivers/net/ethernet/ti] Error 2
> > make[2]: *** [drivers/net/ethernet] Error 2
> > make[1]: *** [drivers/net] Error 2
> >
> > fix for build break as the header file is removed from plat-omap as part of
> > the below patch
>
> linux-next still has this build problem, I guess this patch is lingering
> somewhere. Somewhat annoying, as the driver is enabled by default. (btw,
> why is it "default y"?)
Um, in Linus' master, net, and net-next, neither TI_CPSW nor TI_CPTS
are default y, so I don't know where you are coming from on that.
Sorry,
Richard
^ permalink raw reply
* Re: [RFC] net : add tx timestamp to packet mmap.
From: Richard Cochran @ 2012-12-13 13:29 UTC (permalink / raw)
To: Paul Chavent; +Cc: davem, edumazet, daniel.borkmann, xemul, ebiederm, netdev
In-Reply-To: <1355326165-12277-1-git-send-email-paul.chavent@onera.fr>
On Wed, Dec 12, 2012 at 04:29:25PM +0100, Paul Chavent wrote:
> This patch allow to generate tx timestamps of packets sent by the packet mmap interface.
>
> Actually, you can't get tx timestamps with the sample code below.
>
> I wonder if my current implementation is good. And if not, how should i get the timestamps ?
In order for time stamps to appear, somebody has to call
skb_tx_timestamp() ...
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index e639645..948748b 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1857,6 +1857,10 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
> void *data;
> int err;
>
> + err = sock_tx_timestamp(&po->sk, &skb_shinfo(skb)->tx_flags);
and this call is only setting some flags.
HTH,
Richard
^ permalink raw reply
* [PATCH iproute2 6/6] ip/link_iptnl: fix indentation
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355406174-10586-1-git-send-email-nicolas.dichtel@6wind.com>
Use tabs instead of space when possible.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/link_iptnl.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 238722d..b00d8d9 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -298,10 +298,10 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
fprintf(f, "nopmtudisc ");
if (tb[IFLA_IPTUN_FLAGS]) {
- __u16 iflags = rta_getattr_u16(tb[IFLA_IPTUN_FLAGS]);
+ __u16 iflags = rta_getattr_u16(tb[IFLA_IPTUN_FLAGS]);
- if (iflags & SIT_ISATAP)
- fprintf(f, "isatap ");
+ if (iflags & SIT_ISATAP)
+ fprintf(f, "isatap ");
}
if (tb[IFLA_IPTUN_6RD_PREFIXLEN] &&
@@ -314,12 +314,12 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
printf("6rd-prefix %s/%u ",
inet_ntop(AF_INET6, RTA_DATA(tb[IFLA_IPTUN_6RD_PREFIX]),
- s1, sizeof(s1)),
+ s1, sizeof(s1)),
prefixlen);
if (relayprefix) {
printf("6rd-relay_prefix %s/%u ",
format_host(AF_INET, 4, &relayprefix, s1,
- sizeof(s1)),
+ sizeof(s1)),
relayprefixlen);
}
}
--
1.8.0.1
^ permalink raw reply related
* [PATCH iproute2 5/6] ip: term OPTIONS was used twice in 'ip route' man pages
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355406174-10586-1-git-send-email-nicolas.dichtel@6wind.com>
INFO_SPEC already uses the term 'OPTIONS' and describe it.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
man/man8/ip-route.8.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index f06fcba..2c35a97 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -1,4 +1,4 @@
-.TH IP\-ROUTE 8 "20 Dec 2011" "iproute2" "Linux"
+.TH IP\-ROUTE 8 "13 Dec 2012" "iproute2" "Linux"
.SH "NAME"
ip-route \- routing table management
.SH "SYNOPSIS"
@@ -7,7 +7,7 @@ ip-route \- routing table management
.in +8
.ti -8
.B ip
-.RI "[ " OPTIONS " ]"
+.RI "[ " ip-OPTIONS " ]"
.B route
.RI " { " COMMAND " | "
.BR help " }"
--
1.8.0.1
^ permalink raw reply related
* [PATCH iproute2 4/6] ip: update man pages for 'ip link'
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355406174-10586-1-git-send-email-nicolas.dichtel@6wind.com>
Now 'ip link' supports ipip, sit and ip6tnl.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
man/man8/ip-link.8.in | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 43c4ac6..8d2a6f9 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -1,4 +1,4 @@
-.TH IP\-LINK 8 "20 Dec 2011" "iproute2" "Linux"
+.TH IP\-LINK 8 "13 Dec 2012" "iproute2" "Linux"
.SH "NAME"
ip-link \- network device configuration
.SH "SYNOPSIS"
@@ -59,7 +59,10 @@ ip-link \- network device configuration
.BR vcan " | "
.BR veth " | "
.BR vlan " | "
-.BR vxlan " ]"
+.BR vxlan " |"
+.BR ip6tnl " |"
+.BR ipip " |"
+.BR sit " ]"
.ti -8
.BI "ip link delete " DEVICE
@@ -174,6 +177,15 @@ Link types:
.sp
.BR vxlan
- Virtual eXtended LAN
+.sp
+.BR ip6tnl
+- Virtual tunnel interface IPv4|IPv6 over IPv6
+.sp
+.BR ipip
+- Virtual tunnel interface IPv4 over IPv4
+.sp
+.BR sit
+- Virtual tunnel interface IPv6 over IPv4
.in -8
.TP
--
1.8.0.1
^ permalink raw reply related
* [PATCH iproute2 3/6] ip: update mand pages and usage() for 'ip mroute'
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355406174-10586-1-git-send-email-nicolas.dichtel@6wind.com>
Sync with the current code.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipmroute.c | 2 ++
man/man8/ip-mroute.8 | 14 +++++++++++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index defcfc5..345576d 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -36,6 +36,8 @@ static void usage(void) __attribute__((noreturn));
static void usage(void)
{
fprintf(stderr, "Usage: ip mroute show [ [ to ] PREFIX ] [ from PREFIX ] [ iif DEVICE ]\n");
+ fprintf(stderr, " [ table TABLE_ID ]\n");
+ fprintf(stderr, "TABLE_ID := [ local | main | default | all | NUMBER ]\n");
#if 0
fprintf(stderr, "Usage: ip mroute [ add | del ] DESTINATION from SOURCE [ iif DEVICE ] [ oif DEVICE ]\n");
#endif
diff --git a/man/man8/ip-mroute.8 b/man/man8/ip-mroute.8
index 98aab88..870df5e 100644
--- a/man/man8/ip-mroute.8
+++ b/man/man8/ip-mroute.8
@@ -1,4 +1,4 @@
-.TH IP\-MROUTE 8 "20 Dec 2011" "iproute2" "Linux"
+.TH IP\-MROUTE 8 "13 Dec 2012" "iproute2" "Linux"
.SH "NAME"
ip-mroute \- multicast routing cache management
.SH "SYNOPSIS"
@@ -6,12 +6,15 @@ ip-mroute \- multicast routing cache management
.ad l
.in +8
.ti -8
-.BR "ip mroute show" " ["
+.BR "ip " " [ ip-OPTIONS ] " "mroute show" " [ [ "
+.BR " to " " ] "
.IR PREFIX " ] [ "
.B from
.IR PREFIX " ] [ "
.B iif
-.IR DEVICE " ]"
+.IR DEVICE " ] [ "
+.B table
+.IR TABLE_ID " ] "
.SH DESCRIPTION
.B mroute
@@ -42,6 +45,11 @@ the interface on which multicast packets are received.
.BI from " PREFIX"
the prefix selecting the IP source addresses of the multicast route.
+.TP
+.BI table " TABLE_ID"
+the table id selecting the multicast table. It can be
+.BR local ", " main ", " default ", " all " or a number."
+
.SH SEE ALSO
.br
.BR ip (8)
--
1.8.0.1
^ permalink raw reply related
* [PATCH iproute2 1/6] ip: add man pages for netconf
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
This patch add the documentation about 'ip netconf' command.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
man/man8/Makefile | 2 +-
man/man8/ip-netconf.8 | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 man/man8/ip-netconf.8
diff --git a/man/man8/Makefile b/man/man8/Makefile
index 4bad9d6..d208f3b 100644
--- a/man/man8/Makefile
+++ b/man/man8/Makefile
@@ -9,7 +9,7 @@ MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 \
ip-addrlabel.8 ip-l2tp.8 \
ip-maddress.8 ip-monitor.8 ip-mroute.8 ip-neighbour.8 \
ip-netns.8 ip-ntable.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 \
- ip-tcp_metrics.8
+ ip-tcp_metrics.8 ip-netconf.8
all: $(TARGETS)
diff --git a/man/man8/ip-netconf.8 b/man/man8/ip-netconf.8
new file mode 100644
index 0000000..8041ea2
--- /dev/null
+++ b/man/man8/ip-netconf.8
@@ -0,0 +1,36 @@
+.TH IP\-NETCONF 8 "13 Dec 2012" "iproute2" "Linux"
+.SH "NAME"
+ip-netconf \- network configuration monitoring
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.BR "ip " " [ ip-OPTIONS ] " "netconf show" " [ "
+.B dev
+.IR STRING " ]"
+
+.SH DESCRIPTION
+The
+.B ip netconf
+utility can monitor IPv4 and IPv6 parameters (see
+.BR "/proc/sys/net/ipv[4|6]/conf/[all|DEV]/" ")"
+like forwarding, rp_filter
+or mc_forwarding status.
+
+If no interface is specified, the entry
+.B all
+is displayed.
+
+.SS ip netconf show - display network parameters
+
+.TP
+.BI dev " STRING"
+the name of the device to display network parameters.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Nicolas Dichtel <nicolas.dichtel@6wind.com>
--
1.8.0.1
^ permalink raw reply related
* [PATCH iproute2 2/6] ip: update man pages and usage() for 'ip monitor'
From: Nicolas Dichtel @ 2012-12-13 13:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355406174-10586-1-git-send-email-nicolas.dichtel@6wind.com>
Sync with the current code.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipmonitor.c | 5 ++++-
man/man8/ip-monitor.8 | 15 +++++++++------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 09a339c..a9ff1e8 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -29,7 +29,10 @@ int prefix_banner;
static void usage(void)
{
- fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ]\n");
+ fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ] [ FILE ]\n");
+ fprintf(stderr, "LISTofOBJECTS := link | address | route | mroute | prefix |\n");
+ fprintf(stderr, " neigh | netconf\n");
+ fprintf(stderr, "FILE := file FILENAME\n");
exit(-1);
}
diff --git a/man/man8/ip-monitor.8 b/man/man8/ip-monitor.8
index 351a744..b07cb0e 100644
--- a/man/man8/ip-monitor.8
+++ b/man/man8/ip-monitor.8
@@ -1,4 +1,4 @@
-.TH IP\-MONITOR 8 "20 Dec 2011" "iproute2" "Linux"
+.TH IP\-MONITOR 8 "13 Dec 2012" "iproute2" "Linux"
.SH "NAME"
ip-monitor, rtmon \- state monitoring
.SH "SYNOPSIS"
@@ -6,8 +6,8 @@ ip-monitor, rtmon \- state monitoring
.ad l
.in +8
.ti -8
-.BR "ip monitor" " [ " all " |"
-.IR LISTofOBJECTS " ]"
+.BR "ip " " [ ip-OPTIONS ] " "monitor" " [ " all " |"
+.IR LISTofOBJECTS " ] [ file " FILENAME " ]
.sp
.SH DESCRIPTION
@@ -20,12 +20,13 @@ Namely, the
command is the first in the command line and then the object list follows:
.BR "ip monitor" " [ " all " |"
-.IR LISTofOBJECTS " ]"
+.IR LISTofOBJECTS " ] [ file " FILENAME " ]
.I OBJECT-LIST
is the list of object types that we want to monitor.
It may contain
-.BR link ", " address " and " route "."
+.BR link ", " address ", " route ", " mroute ", " prefix ", "
+.BR neigh " and " netconf "."
If no
.B file
argument is given,
@@ -34,7 +35,9 @@ opens RTNETLINK, listens on it and dumps state changes in the format
described in previous sections.
.P
-If a file name is given, it does not listen on RTNETLINK,
+If a
+.I FILENAME
+is given, it does not listen on RTNETLINK,
but opens the file containing RTNETLINK messages saved in binary format
and dumps them. Such a history file can be generated with the
.B rtmon
--
1.8.0.1
^ permalink raw reply related
* Re: [RFC PATCH net-next 4/4 V4] try to fix performance regression
From: Weiping Pan @ 2012-12-13 14:05 UTC (permalink / raw)
To: David Laight; +Cc: davem, brutus, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70ED@saturn3.aculab.com>
On 12/12/2012 10:57 PM, David Laight wrote:
>> MS BASE AF_UNIX FRIENDS TCP_STREAM_MS
>> 1 10.70 5.40 4.02 37% 74%
>> 2 28.01 9.67 7.97 28% 82%
>> 4 55.53 19.78 16.48 29% 83%
>> 8 115.40 38.22 33.51 29% 87%
>> 16 227.31 81.06 67.70 29% 83%
>> 32 446.20 166.59 129.31 28% 77%
>> 64 849.04 336.77 259.43 30% 77%
>> 128 1440.50 661.88 530.43 36% 80%
>> 256 2404.70 1279.67 1029.15 42% 80%
>> 512 4331.53 2501.30 1942.21 44% 77%
>> 1024 6819.78 4622.37 4128.10 60% 89%
>> 2048 10544.60 6348.81 6349.59 60% 100%
>> 4096 12830.41 8324.43 7984.43 62% 95%
>> 8192 13462.65 8355.49 11079.37 82% 132%
>> 16384 9960.87 10840.13 13037.81 130% 120%
>> 32768 8749.31 11372.15 15087.08 172% 132%
>> 65536 7580.27 12150.23 14971.42 197% 123%
>> 131072 6727.74 11451.34 13604.78 202% 118%
>> 262144 7673.14 11613.10 11436.97 149% 98%
>> 524288 7366.17 11675.95 11559.43 156% 99%
>> 1048576 6608.57 11883.01 10103.20 152% 85%
>> MS means Message Size in bytes, that is -m -M for netperf
> If I read that table correctly, it seems to imply that
> something goes badly wrong for 'normal' TCP loopback
> connections when the read/write size exceeds 8k.
> Putting effort into fixing that would appear to be
> more worthwhile than the 'friends' code.
>
> David
>
Hi, David,
In my test program, I run normal tcp loopback then friends for each
message size,
then it generates such strange numbers.
But if I just run normal tcp loopback for each message size, then the
performance is stable.
[root@intel-s3e3432-01 ~]# cat base.sh
for s in 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
65536 131072 262144 524288 1048576
do
netperf -i -2,10 -I 95,20 -- -m $s -M $s | tail -n1
done
87380 16384 1 10.09 15.51
87380 16384 2 10.01 31.39
87380 16384 4 10.00 55.78
87380 16384 8 10.00 115.17
87380 16384 16 10.00 231.66
87380 16384 32 10.00 452.42
87380 16384 64 10.00 859.92
87380 16384 128 10.00 1464.91
87380 16384 256 10.00 2613.12
87380 16384 512 10.00 4338.88
87380 16384 1024 10.00 7174.22
87380 16384 2048 10.00 10452.84
87380 16384 4096 10.00 11932.33
87380 16384 8192 10.00 13750.49
87380 16384 16384 10.00 13196.98
87380 16384 32768 10.00 14881.25
87380 16384 65536 10.00 13685.36
87380 16384 131072 10.00 16088.71
87380 16384 262144 10.00 17193.86
87380 16384 524288 10.00 16696.07
87380 16384 1048576 10.00 13638.13
thanks
Weiping Pan
^ permalink raw reply
* Re: [RFC PATCH net-next 4/4 V4] try to fix performance regression
From: Weiping Pan @ 2012-12-13 14:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, brutus, netdev
In-Reply-To: <1355329523.9139.578.camel@edumazet-glaptop>
On 12/13/2012 12:25 AM, Eric Dumazet wrote:
> On Wed, 2012-12-12 at 22:29 +0800, Weiping Pan wrote:
>
>> MS BASE AF_UNIX FRIENDS TCP_STREAM_MS
>> 1 10.70 5.40 4.02 37% 74%
>> 2 28.01 9.67 7.97 28% 82%
>> 4 55.53 19.78 16.48 29% 83%
>> 8 115.40 38.22 33.51 29% 87%
>> 16 227.31 81.06 67.70 29% 83%
>> 32 446.20 166.59 129.31 28% 77%
>> 64 849.04 336.77 259.43 30% 77%
>> 128 1440.50 661.88 530.43 36% 80%
>> 256 2404.70 1279.67 1029.15 42% 80%
>> 512 4331.53 2501.30 1942.21 44% 77%
>> 1024 6819.78 4622.37 4128.10 60% 89%
>> 2048 10544.60 6348.81 6349.59 60% 100%
>> 4096 12830.41 8324.43 7984.43 62% 95%
>> 8192 13462.65 8355.49 11079.37 82% 132%
>> 16384 9960.87 10840.13 13037.81 130% 120%
>> 32768 8749.31 11372.15 15087.08 172% 132%
>> 65536 7580.27 12150.23 14971.42 197% 123%
>> 131072 6727.74 11451.34 13604.78 202% 118%
>> 262144 7673.14 11613.10 11436.97 149% 98%
>> 524288 7366.17 11675.95 11559.43 156% 99%
>> 1048576 6608.57 11883.01 10103.20 152% 85%
>> MS means Message Size in bytes, that is -m -M for netperf
> I cant reproduce your strange numbers here, they make no sense to me.
>
> for s in 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
> 65536 131072 262144 524288 1048576
> do
> ./netperf -- -m $s -M $s | tail -n1
> done
>
> Results :
>
> 87380 16384 1 10.00 34.68
> 87380 16384 2 10.00 68.07
> 87380 16384 4 10.00 126.27
> 87380 16384 8 10.00 284.50
> 87380 16384 16 10.00 574.38
> 87380 16384 32 10.00 1091.74
> 87380 16384 64 10.00 2130.23
> 87380 16384 128 10.00 4001.83
> 87380 16384 256 10.00 7666.01
> 87380 16384 512 10.00 13425.81
> 87380 16384 1024 10.00 21146.43
> 87380 16384 2048 10.00 28551.42
> 87380 16384 4096 10.00 37878.95
> 87380 16384 8192 10.00 42507.23
> 87380 16384 16384 10.00 46782.53
> 87380 16384 32768 10.00 42410.97
> 87380 16384 65536 10.00 43053.09
> 87380 16384 131072 10.00 44504.20
> 87380 16384 262144 10.00 50211.74
> 87380 16384 524288 10.00 54004.23
> 87380 16384 1048576 10.00 53852.26
>
>
>
Hi, Eric,
In my test program, I run normal tcp loopback then friends for each
message size,
then it generates such strange numbers.
But if I just run normal tcp loopback for each message size, then the
performance is stable.
Maybe I should make the environment clean before each test, like
dropping cache.
thanks
Weiping Pan
^ permalink raw reply
* [PATCH] ndisc: Fix padding error in link-layer address option.
From: YOSHIFUJI Hideaki @ 2012-12-13 14:29 UTC (permalink / raw)
To: davem, netdev; +Cc: yoshfuji
If a natural number n exists where 2 + data_len <= 8n < 2 + data_len + pad,
post padding is not initialized correctly.
(Un)fortunately, the only type that requires pad is Infiniband,
whose pad is 2 and data_len is 20, and this logical error has not
become obvious, but it is better to fix.
Note that ndisc_opt_addr_space() handles the situation described
above correctly.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/ipv6/ndisc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 92909d2..2ed42c8 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -151,8 +151,8 @@ static inline int ndisc_opt_addr_space(struct net_device *dev)
static u8 *ndisc_fill_addr_option(u8 *opt, int type, void *data, int data_len,
unsigned short addr_type)
{
- int space = NDISC_OPT_SPACE(data_len);
int pad = ndisc_addr_option_pad(addr_type);
+ int space = NDISC_OPT_SPACE(data_len + pad);
opt[0] = type;
opt[1] = space>>3;
--
1.7.9.5
^ permalink raw reply related
* Re: netconsole fun
From: Peter Hurley @ 2012-12-13 14:49 UTC (permalink / raw)
To: Neil Horman; +Cc: Cong Wang, netdev
In-Reply-To: <20121213123611.GA12269@hmsreliant.think-freely.org>
On Thu, 2012-12-13 at 07:36 -0500, Neil Horman wrote:
> On Wed, Dec 12, 2012 at 03:59:17PM -0500, Peter Hurley wrote:
> > On Tue, 2012-12-11 at 11:45 -0500, Neil Horman wrote:
> > > On Tue, Dec 11, 2012 at 10:16:51AM -0500, Peter Hurley wrote:
> > > > On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> > > > > On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > > > > > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > > > > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > > > > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > > > > > recommended method of running netconsole on a machine that has a slaved
> > > > > > > > device?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, running it on the master device instead.
> > > > > >
> > > > > > Thanks for the suggestion, but:
> > > > > >
> > > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.10.99/br0,30000@192.168.10.100/xx:xx:xx:xx:xx:xx
> > > > > > ...
> > > > > > [ 5.289869] netpoll: netconsole: local port 6665
> > > > > > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > > > > > [ 5.289892] netpoll: netconsole: interface 'br0'
> > > > > > [ 5.289898] netpoll: netconsole: remote port 30000
> > > > > > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > > > > > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > > > > > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > > > > > [ 5.289929] netconsole: cleaning up
> > > > > > ...
> > > > > > [ 9.392291] Bridge firewalling registered
> > > > > > [ 9.396805] device eth1 entered promiscuous mode
> > > > > > [ 9.418350] eth1: setting full-duplex.
> > > > > > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > > > > > [ 9.423354] br0: port 1(eth1) entered forwarding state
> > > > > >
> > > > > >
> > > > > > Is there a way to control or associate network device names prior to
> > > > > > udev renaming?
> > > > > >
> > > > > That looks like a systemd problem (or more specifically a boot dependency
> > > > > problem). You need to modify your netconsole unit/service file to start after
> > > > > all your networking is up. NetworkManager provides a dummy service file for
> > > > > this purpose, called networkmanager-wait-online.service
> > > >
> > > > Ok. So with a single physical network interface that will be bridged,
> > > > netconsole cannot used for kernel boot messages.
> > > >
> > > > With a machine with multiple nics, is there a way to control device
> > > > naming so that the interface name to be used by netconsole specified on
> > > > the boot command line will actually corresponding to the intended
> > > > device. For example,
> > > >
> > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.1.123/eth0,30000@192.168.1.139/xx:xx:xx:xx:xx:xx
> > > > ....
> > > > [ 4.092184] 3c59x: Donald Becker and others.
> > > > [ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
> > > > [ 4.094035] tg3.c:v3.125 (September 26, 2012)
> > > > ....
> > > > [ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > > > [ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > > [ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > > > [ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
> > > >
> > > > This is attaching netconsole to the wrong device because bus
> > > > enumeration, and therefore load order, is not consistent from boot to
> > > > boot.
> > > >
> > > No, theres no way to do that. As you note device ennumeration isn't consistent
> > > accross boots, thats why udev creates rules to rename devices based on immutable
> > > (or semi-immutable) data, like mac addresses, or pci bus locations). Once that
> > > happens, you'll have consistent names for your interfaces, and that work will be
> > > guaranteed to be done after networkmanager has finished opening all the
> > > interfaces that it needs (hence my suggestion to make netconsole service
> > > dependent on networkmanager service startup completing).
> >
> > Just wondering if you think something like the patch below is
> > suitable/acceptable for insulating netconsole from inconsistent device
> > name scenarios without changing the existing semantics. The basic idea
> > is to allow an ethernet MAC address in the <dev> field of the
> > netconsole= options, and if a MAC address was specified rather than a
> > device name, to do the dev lookup from the MAC address instead.
> >
> > This doesn't extend to, but also doesn't interfere with, the dynamic
> > config of netconsole via configfs.
> >
> > Would you mind reviewing it?
> >
> > Regards,
> > Peter
> >
> This looks like a pretty good idea to me. That said, something occured to me
> when you wrote your summary above. Have you looked at the netconsole service
> scripts that most distros provide in their packaging? I'm almost positive Red
> Hat/Fedora (and also like Suse and Ubuntu), already implement this functionality
> from user space. Basically, instead of people just modprobing netconsole, they
> create a service script that parses a config file that has contains all the
> options needed to load the netconsole module, and it has the intellegence to see
> if you specified a mac address rather than a device. If you did that it finds
> the corresponding device mac address and uses that as the device. I'm sorry, I
> don't know why I didn't think of that before. Check that out though, that will
> likey give you exactly what you need
Even with a udev rule to load netconsole that runs immediately after
device renaming (so before scripting), most of the dynamic module
loading has already happened so netconsole misses it. At least with the
patch, netconsole will load and attach to the proper interface much
earlier in the boot so that module-load-time messages will be caught.
There is an unforeseen consequence of the patch: it breaks device
renaming because the device will already be in use by netconsole. Which
is the whole problem with userspace device renaming to begin with...
I guess that leaves only the option of building in netconsole and the
driver that supplies the interface.
Oh well.
Regards,
Peter
^ permalink raw reply
* Re: GPF in skb_flow_dissect
From: Dave Jones @ 2012-12-13 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jason Wang, David Miller, netdev
In-Reply-To: <1355376177.12271.244.camel@edumazet-glaptop>
On Wed, Dec 12, 2012 at 09:22:57PM -0800, Eric Dumazet wrote:
> Yes, commit 7694a3acc55a7 added this bug
>
> Its illegal to use skb after call to netif_rx_ni(skb);
>
> I would try following patch.
Looks like it does the right thing. Thanks Eric.
Dave
^ permalink raw reply
* [PATCH net-next] net: ethool: Document struct ethtool_flow_ext
From: Yan Burman @ 2012-12-13 15:20 UTC (permalink / raw)
To: Or Gerlitz, Amir Vadai, netdev, David S. Miller, Ben Hutchings; +Cc: Yan Burman
Add documentation for struct ethtool_flow_ext especially in regard
to what flags are needed for which fields.
Signed-off-by: Yan Burman <yanb@mellanox.com>
---
include/uapi/linux/ethtool.h | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index be8c41e..0c9b448 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -503,9 +503,20 @@ union ethtool_flow_union {
__u8 hdata[52];
};
+/**
+ * struct ethtool_flow_ext - additional RX flow fields
+ * @h_dest: destination MAC address
+ * @vlan_etype: VLAN EtherType
+ * @vlan_tci: VLAN tag control information
+ * @data: user defined data
+ *
+ * Note, @vlan_etype, @vlan_tci, and @data are only valid if %FLOW_EXT
+ * is set in &struct ethtool_rx_flow_spec @flow_type.
+ * @h_dest is valid if %FLOW_MAC_EXT is set.
+ */
struct ethtool_flow_ext {
__u8 padding[2];
- unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
+ unsigned char h_dest[ETH_ALEN];
__be16 vlan_etype;
__be16 vlan_tci;
__be32 data[2];
@@ -519,7 +530,8 @@ struct ethtool_flow_ext {
* @m_u: Masks for flow field bits to be matched
* @m_ext: Masks for additional field bits to be matched
* Note, all additional fields must be ignored unless @flow_type
- * includes the %FLOW_EXT flag.
+ * includes the %FLOW_EXT or %FLOW_MAC_EXT flag
+ * (see &struct ethtool_flow_ext description).
* @ring_cookie: RX ring/queue index to deliver to, or %RX_CLS_FLOW_DISC
* if packets should be discarded
* @location: Location of rule in the table. Locations must be
--
1.7.11.3
^ permalink raw reply related
* Re: [RFC] net : add tx timestamp to packet mmap.
From: Paul Chavent @ 2012-12-13 16:13 UTC (permalink / raw)
To: Richard Cochran; +Cc: davem, edumazet, daniel.borkmann, xemul, ebiederm, netdev
In-Reply-To: <20121213132916.GB10703@netboy.at.omicron.at>
Hello.
On 12/13/2012 02:29 PM, Richard Cochran wrote:
> On Wed, Dec 12, 2012 at 04:29:25PM +0100, Paul Chavent wrote:
>> This patch allow to generate tx timestamps of packets sent by the packet mmap interface.
>>
>> Actually, you can't get tx timestamps with the sample code below.
>>
>> I wonder if my current implementation is good. And if not, how should i get the timestamps ?
>
> In order for time stamps to appear, somebody has to call
> skb_tx_timestamp() ...
Yes. "Somebody" means "the hardware driver" after completing xmit.
That's true ?
>
>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>> index e639645..948748b 100644
>> --- a/net/packet/af_packet.c
>> +++ b/net/packet/af_packet.c
>> @@ -1857,6 +1857,10 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
>> void *data;
>> int err;
>>
>> + err = sock_tx_timestamp(&po->sk, &skb_shinfo(skb)->tx_flags);
>
> and this call is only setting some flags.
Yes, it only sets some flags. I thought that those flags was required by
the skb_tx_timestamp() in order to make the appropriate timestamping
(hardware, software, etc).
So in order to have tx timestamp that work, both calls are needed ?
Why sock_tx_timestamp is called in packet_fill_skb and
packet_sendmsg_spkt and not in tpacket_fill_skb ?
Why i can retrieve timestamps when i add this call ?
>
> HTH,
> Richard
>
Thank for your help.
Paul.
^ 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