* Re: [PATCH next-next 0/7] net: Cleanup IPv6 ip tunnels
From: Tom Herbert @ 2016-05-02 19:32 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UfwyZW7kifpU18xtwT77=Zex3AzJp=xry=siW1NVCyX+A@mail.gmail.com>
On Fri, Apr 29, 2016 at 6:00 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, Apr 29, 2016 at 5:12 PM, Tom Herbert <tom@herbertland.com> wrote:
>> The IPv6 tunnel code is very different from IPv4 code. There is a lot
>> of redundancy with the IPv4 code, particularly in the GRE tunneling.
>>
>> This patch set cleans up the tunnel code to make the IPv6 code look
>> more like the IPv4 code and use common functions between the two
>> stacks where possible.
>>
>> This work should make it easier to maintain and extend the IPv6 ip
>> tunnels.
>>
>> Items in this patch set:
>> - Cleanup IPv6 tunnel receive path (ip6_tnl_rcv). Includes using
>> gro_cells and exporting ip6_tnl_rcv so the ip6_gre can call it
>> - Move GRE functions to common header file (tx functions) or
>> gre_demux.c (rx functions like gre_parse_header)
>> - Call common GRE functions from IPv6 GRE
>> - Create ip6_tnl_xmit (to be like ip_tunnel_xmit)
>>
>> Tested:
>> Ran super_netperf tests for TCP_RR and TCP_STREAM for:
>> - IPv4 over gre, gretap, gre6, gre6tap
>> - IPv6 over gre, gretap, gre6, gre6tap
>> - ipip
>> - ip6ip6
>> - ipip/gue
>> - IPv6 over gre/gue
>> - IPv4 over gre/gue
>
> You should probably add 2 additional test cases. One for IPv4 GRE/GUE
> w/ checksum on the GRE header, and same for IPv6. It was broken
> previously in terms of offloads so we need to make sure we don't
> introduce a regression and break it again.
>
Hi Alexander,
I did test GRE/GUE with checksum and remcsum for IPv4, that works okay.
Support for GUE with IPv6 is in the next patch set I am working on.
Thanks,
Tom
>> Tom Herbert (7):
>> ipv6: Cleanup IPv6 tunnel receive path
>> gre: Move utility functions to common headers
>> gre6: Cleanup GREv6 receive path, call common GRE functions
>> ipv6: Create ip6_tnl_xmit
>> gre: Create common functions for transmit
>> ipv6: Generic tunnel cleanup
>> gre6: Cleanup GREv6 transmit path, call common GRE functions
>>
>> include/net/gre.h | 104 +++++++++++++
>> include/net/ip6_tunnel.h | 11 +-
>> net/ipv4/gre_demux.c | 64 ++++++++
>> net/ipv4/ip_gre.c | 199 +++---------------------
>> net/ipv6/ip6_gre.c | 392 +++++++++--------------------------------------
>> net/ipv6/ip6_tunnel.c | 266 +++++++++++++++++++++-----------
>> 6 files changed, 452 insertions(+), 584 deletions(-)
>>
>> --
>> 2.8.0.rc2
>>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use hci_conn_hash_lookup_le
From: Julia Lawall @ 2016-05-02 19:33 UTC (permalink / raw)
To: Johan Hedberg
Cc: Julia Lawall, Marcel Holtmann, kernel-janitors, Gustavo Padovan,
David S. Miller, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <20160502180256.GA22757@t440s>
On Mon, 2 May 2016, Johan Hedberg wrote:
> Hi,
>
> On Fri, Apr 29, 2016, Julia Lawall wrote:
> > --- a/net/bluetooth/mgmt.c
> > +++ b/net/bluetooth/mgmt.c
> > @@ -4773,7 +4773,8 @@ static int get_conn_info(struct sock *sk, struct hci_dev *hdev, void *data,
> > conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK,
> > &cp->addr.bdaddr);
> > else
> > - conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &cp->addr.bdaddr);
> > + conn = hci_conn_hash_lookup_le(hdev, &cp->addr.bdaddr,
> > + cp->addr.type);
>
> I don't think is is correct. There are two possible domains for address
> types: the user space-facing interface that has three values: BR/EDR, LE
> public & LE random, and the internal one which maps to HCI that has two
> values: random or public. You'd need to convert from the former to the
> latter when making the lookup call, i.e:
>
> conn = hci_conn_hash_lookup_le(hdev, &cp->addr.bdaddr,
> le_addr_type(cp->addr.type));
OK, thanks for the feedback.
julia
>
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 bluetooth-next 07/10] ipv6: introduce neighbour discovery ops
From: Hannes Frederic Sowa @ 2016-05-02 19:36 UTC (permalink / raw)
To: Alexander Aring, linux-wpan
Cc: kernel, marcel, jukka.rissanen, stefan, mcr, werner,
linux-bluetooth, netdev, David S . Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1461140382-4784-8-git-send-email-aar@pengutronix.de>
On 20.04.2016 10:19, Alexander Aring wrote:
> This patch introduces neighbour discovery ops callback structure. The
> structure contains at first receive and transmit handling for NS/NA and
> userspace option field functionality.
>
> These callback offers 6lowpan different handling, such as 802.15.4 short
> address handling or RFC6775 (Neighbor Discovery Optimization for IPv6 over
> 6LoWPANs).
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Alexander Aring <aar@pengutronix.de>
> ---
> include/linux/netdevice.h | 3 ++
> include/net/ndisc.h | 96 +++++++++++++++++++++++++++++++++++++++++++----
> net/ipv6/addrconf.c | 1 +
> net/ipv6/ndisc.c | 71 ++++++++++++++++++++++++-----------
> net/ipv6/route.c | 2 +-
> 5 files changed, 144 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 0052c42..bc60033 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1677,6 +1677,9 @@ struct net_device {
> #ifdef CONFIG_NET_L3_MASTER_DEV
> const struct l3mdev_ops *l3mdev_ops;
> #endif
> +#if IS_ENABLED(CONFIG_IPV6)
> + const struct ndisc_ops *ndisc_ops;
> +#endif
>
> const struct header_ops *header_ops;
>
> diff --git a/include/net/ndisc.h b/include/net/ndisc.h
> index aac868e..14ed016 100644
> --- a/include/net/ndisc.h
> +++ b/include/net/ndisc.h
> @@ -110,7 +110,8 @@ struct ndisc_options {
>
> #define NDISC_OPT_SPACE(len) (((len)+2+7)&~7)
>
> -struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
> +struct ndisc_options *ndisc_parse_options(const struct net_device *dev,
> + u8 *opt, int opt_len,
> struct ndisc_options *ndopts);
>
> /*
> @@ -173,6 +174,93 @@ static inline struct neighbour *__ipv6_neigh_lookup(struct net_device *dev, cons
> return n;
> }
>
> +static inline int __ip6_ndisc_is_useropt(struct nd_opt_hdr *opt)
> +{
> + return opt->nd_opt_type == ND_OPT_RDNSS ||
> + opt->nd_opt_type == ND_OPT_DNSSL;
> +}
> +
> +#if IS_ENABLED(CONFIG_IPV6)
> +struct ndisc_ops {
> + int (*is_useropt)(struct nd_opt_hdr *opt);
> + void (*send_na)(struct net_device *dev,
> + const struct in6_addr *daddr,
> + const struct in6_addr *solicited_addr,
> + bool router, bool solicited,
> + bool override, bool inc_opt);
> + void (*recv_na)(struct sk_buff *skb);
> + void (*send_ns)(struct net_device *dev,
> + const struct in6_addr *solicit,
> + const struct in6_addr *daddr,
> + const struct in6_addr *saddr);
> + void (*recv_ns)(struct sk_buff *skb);
> +};
> +
> +static inline int ndisc_is_useropt(const struct net_device *dev,
> + struct nd_opt_hdr *opt)
> +{
> + if (likely(dev->ndisc_ops->is_useropt))
> + return dev->ndisc_ops->is_useropt(opt);
> + else
> + return 0;
> +}
> +
> +static inline void ndisc_send_na(struct net_device *dev,
> + const struct in6_addr *daddr,
> + const struct in6_addr *solicited_addr,
> + bool router, bool solicited, bool override,
> + bool inc_opt)
> +{
> + if (likely(dev->ndisc_ops->send_na))
> + dev->ndisc_ops->send_na(dev, daddr, solicited_addr, router,
> + solicited, override, inc_opt);
> +}
> +
> +static inline void ndisc_recv_na(struct sk_buff *skb)
> +{
> + if (likely(skb->dev->ndisc_ops->recv_na))
> + skb->dev->ndisc_ops->recv_na(skb);
> +}
> +
> +static inline void ndisc_send_ns(struct net_device *dev,
> + const struct in6_addr *solicit,
> + const struct in6_addr *daddr,
> + const struct in6_addr *saddr)
> +{
> + if (likely(dev->ndisc_ops->send_ns))
> + dev->ndisc_ops->send_ns(dev, solicit, daddr, saddr);
> +}
> +
> +static inline void ndisc_recv_ns(struct sk_buff *skb)
> +{
> + if (likely(skb->dev->ndisc_ops->recv_ns))
> + skb->dev->ndisc_ops->recv_ns(skb);
> +}
> +#else
> +static inline int ndisc_is_useropt(const struct net_device *dev,
> + struct nd_opt_hdr *opt)
> +{
> + return 0;
> +}
> +
> +static inline void ndisc_send_na(struct net_device *dev,
> + const struct in6_addr *daddr,
> + const struct in6_addr *solicited_addr,
> + bool router, bool solicited, bool override,
> + bool inc_opt) { }
> +
> +static inline void ndisc_recv_na(struct sk_buff *skb) { }
> +
> +static inline void ndisc_send_ns(struct net_device *dev,
> + const struct in6_addr *solicit,
> + const struct in6_addr *daddr,
> + const struct in6_addr *saddr) { }
> +
> +static inline void ndisc_recv_ns(struct sk_buff *skb) { }
> +#endif
Do those empty functions actually make sense? I wonder a bit because
6lowpan strictly depends on ipv6 and they should never be called without
IPv6, no?
> +
> +void ip6_register_ndisc_ops(struct net_device *dev);
> +
> int ndisc_init(void);
> int ndisc_late_init(void);
>
> @@ -181,14 +269,8 @@ void ndisc_cleanup(void);
>
> int ndisc_rcv(struct sk_buff *skb);
>
> -void ndisc_send_ns(struct net_device *dev, const struct in6_addr *solicit,
> - const struct in6_addr *daddr, const struct in6_addr *saddr);
> -
> void ndisc_send_rs(struct net_device *dev,
> const struct in6_addr *saddr, const struct in6_addr *daddr);
> -void ndisc_send_na(struct net_device *dev, const struct in6_addr *daddr,
> - const struct in6_addr *solicited_addr,
> - bool router, bool solicited, bool override, bool inc_opt);
>
> void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target);
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 54e18c2..a2ef04b 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3266,6 +3266,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
> idev = ipv6_add_dev(dev);
> if (IS_ERR(idev))
> return notifier_from_errno(PTR_ERR(idev));
> + ip6_register_ndisc_ops(dev);
Is it possible to register the ndisc options before we make the device
visible to the stack? Maybe even as a pointer to ipv6_add_dev.
> }
> break;
>
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 176c7c4..297080a 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -185,24 +185,25 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
> return cur <= end && cur->nd_opt_type == type ? cur : NULL;
> }
>
> -static inline int ndisc_is_useropt(struct nd_opt_hdr *opt)
> +static inline int ip6_ndisc_is_useropt(struct nd_opt_hdr *opt)
> {
> - return opt->nd_opt_type == ND_OPT_RDNSS ||
> - opt->nd_opt_type == ND_OPT_DNSSL;
> + return __ip6_ndisc_is_useropt(opt);
> }
inline in C functions are not necessary.
>
> -static struct nd_opt_hdr *ndisc_next_useropt(struct nd_opt_hdr *cur,
> +static struct nd_opt_hdr *ndisc_next_useropt(const struct net_device *dev,
> + struct nd_opt_hdr *cur,
> struct nd_opt_hdr *end)
> {
> if (!cur || !end || cur >= end)
> return NULL;
> do {
> cur = ((void *)cur) + (cur->nd_opt_len << 3);
> - } while (cur < end && !ndisc_is_useropt(cur));
> - return cur <= end && ndisc_is_useropt(cur) ? cur : NULL;
> + } while (cur < end && !ndisc_is_useropt(dev, cur));
> + return cur <= end && ndisc_is_useropt(dev, cur) ? cur : NULL;
> }
>
> -struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
> +struct ndisc_options *ndisc_parse_options(const struct net_device *dev,
> + u8 *opt, int opt_len,
> struct ndisc_options *ndopts)
> {
> struct nd_opt_hdr *nd_opt = (struct nd_opt_hdr *)opt;
> @@ -243,7 +244,7 @@ struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
> break;
> #endif
> default:
> - if (ndisc_is_useropt(nd_opt)) {
> + if (ndisc_is_useropt(dev, nd_opt)) {
> ndopts->nd_useropts_end = nd_opt;
> if (!ndopts->nd_useropts)
> ndopts->nd_useropts = nd_opt;
> @@ -479,9 +480,11 @@ static void ndisc_send_skb(struct sk_buff *skb,
> rcu_read_unlock();
> }
>
> -void ndisc_send_na(struct net_device *dev, const struct in6_addr *daddr,
> - const struct in6_addr *solicited_addr,
> - bool router, bool solicited, bool override, bool inc_opt)
> +static void ip6_ndisc_send_na(struct net_device *dev,
> + const struct in6_addr *daddr,
> + const struct in6_addr *solicited_addr,
> + bool router, bool solicited, bool override,
> + bool inc_opt)
> {
> struct sk_buff *skb;
> struct in6_addr tmpaddr;
> @@ -555,8 +558,10 @@ static void ndisc_send_unsol_na(struct net_device *dev)
> in6_dev_put(idev);
> }
>
> -void ndisc_send_ns(struct net_device *dev, const struct in6_addr *solicit,
> - const struct in6_addr *daddr, const struct in6_addr *saddr)
> +static void ip6_ndisc_send_ns(struct net_device *dev,
> + const struct in6_addr *solicit,
> + const struct in6_addr *daddr,
> + const struct in6_addr *saddr)
> {
> struct sk_buff *skb;
> struct in6_addr addr_buf;
> @@ -702,7 +707,7 @@ static int pndisc_is_router(const void *pkey,
> return ret;
> }
>
> -static void ndisc_recv_ns(struct sk_buff *skb)
> +static void ip6_ndisc_recv_ns(struct sk_buff *skb)
> {
> struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
> const struct in6_addr *saddr = &ipv6_hdr(skb)->saddr;
> @@ -738,7 +743,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
> return;
> }
>
> - if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) {
> + if (!ndisc_parse_options(dev, msg->opt, ndoptlen, &ndopts)) {
> ND_PRINTK(2, warn, "NS: invalid ND options\n");
> return;
> }
> @@ -874,7 +879,7 @@ out:
> in6_dev_put(idev);
> }
>
> -static void ndisc_recv_na(struct sk_buff *skb)
> +static void ip6_ndisc_recv_na(struct sk_buff *skb)
> {
> struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
> struct in6_addr *saddr = &ipv6_hdr(skb)->saddr;
> @@ -912,7 +917,7 @@ static void ndisc_recv_na(struct sk_buff *skb)
> idev->cnf.drop_unsolicited_na)
> return;
>
> - if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) {
> + if (!ndisc_parse_options(dev, msg->opt, ndoptlen, &ndopts)) {
> ND_PRINTK(2, warn, "NS: invalid ND option\n");
> return;
> }
> @@ -1019,7 +1024,7 @@ static void ndisc_recv_rs(struct sk_buff *skb)
> goto out;
>
> /* Parse ND options */
> - if (!ndisc_parse_options(rs_msg->opt, ndoptlen, &ndopts)) {
> + if (!ndisc_parse_options(skb->dev, rs_msg->opt, ndoptlen, &ndopts)) {
> ND_PRINTK(2, notice, "NS: invalid ND option, ignored\n");
> goto out;
> }
> @@ -1137,7 +1142,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
> return;
> }
>
> - if (!ndisc_parse_options(opt, optlen, &ndopts)) {
> + if (!ndisc_parse_options(skb->dev, opt, optlen, &ndopts)) {
> ND_PRINTK(2, warn, "RA: invalid ND options\n");
> return;
> }
> @@ -1424,7 +1429,8 @@ skip_routeinfo:
> struct nd_opt_hdr *p;
> for (p = ndopts.nd_useropts;
> p;
> - p = ndisc_next_useropt(p, ndopts.nd_useropts_end)) {
> + p = ndisc_next_useropt(skb->dev, p,
> + ndopts.nd_useropts_end)) {
> ndisc_ra_useropt(skb, p);
> }
> }
> @@ -1462,7 +1468,7 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
> return;
> }
>
> - if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
> + if (!ndisc_parse_options(skb->dev, msg->opt, ndoptlen, &ndopts))
> return;
>
> if (!ndopts.nd_opts_rh) {
> @@ -1783,6 +1789,29 @@ int ndisc_ifinfo_sysctl_change(struct ctl_table *ctl, int write, void __user *bu
>
> #endif
>
> +static const struct ndisc_ops ip6_ndisc_ops = {
> + .is_useropt = ip6_ndisc_is_useropt,
> + .send_na = ip6_ndisc_send_na,
> + .recv_na = ip6_ndisc_recv_na,
> + .send_ns = ip6_ndisc_send_ns,
> + .recv_ns = ip6_ndisc_recv_ns,
> +};
> +
> +void ip6_register_ndisc_ops(struct net_device *dev)
> +{
> + switch (dev->type) {
> + default:
> + if (dev->ndisc_ops) {
> + ND_PRINTK(2, warn,
> + "%s: ndisc_ops already defined for interface type=%d\n",
> + __func__, dev->type);
> + } else {
> + dev->ndisc_ops = &ip6_ndisc_ops;
> + }
> + break;
I would be more stricht with validation:
if (!WARN_ON(dev->ndisc_ops))
dev->ndisc_ops = &ip6_ndisc_ops;
> + }
> +}
> +
> static int __net_init ndisc_net_init(struct net *net)
> {
> struct ipv6_pinfo *np;
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cc180b3..5fa276d 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2149,7 +2149,7 @@ static void rt6_do_redirect(struct dst_entry *dst, struct sock *sk, struct sk_bu
> * first-hop router for the specified ICMP Destination Address.
> */
>
> - if (!ndisc_parse_options(msg->opt, optlen, &ndopts)) {
> + if (!ndisc_parse_options(skb->dev, msg->opt, optlen, &ndopts)) {
> net_dbg_ratelimited("rt6_redirect: invalid ND options\n");
> return;
> }
>
^ permalink raw reply
* Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr_space
From: Hannes Frederic Sowa @ 2016-05-02 19:37 UTC (permalink / raw)
To: Alexander Aring, linux-wpan
Cc: kernel, marcel, jukka.rissanen, stefan, mcr, werner,
linux-bluetooth, netdev, David S . Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1461140382-4784-5-git-send-email-aar@pengutronix.de>
On 20.04.2016 10:19, Alexander Aring wrote:
> This patch makes the address length as argument for the
> ndisc_opt_addr_space function. This is necessary to handle addresses
> which don't use dev->addr_len as address length.
Would it make sense for patch 4, 5 and 6 to add the operation to ndisc_ops?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v2] net: macb: do not scan PHYs manually
From: Josh Cartwright @ 2016-05-02 19:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: Nicolas Ferre, Andrew Lunn, Nathan Sullivan, netdev, linux-kernel,
Alexandre Belloni
In-Reply-To: <5727A5C2.804@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]
On Mon, May 02, 2016 at 12:08:50PM -0700, Florian Fainelli wrote:
> On 02/05/16 11:36, Josh Cartwright wrote:
> > On Fri, Apr 29, 2016 at 02:40:53PM +0200, Nicolas Ferre wrote:
> > [..]
> >>> static int macb_mii_init(struct macb *bp)
> >>> {
> >>> struct macb_platform_data *pdata;
> >>> struct device_node *np;
> >>> - int err = -ENXIO, i;
> >>> + int err = -ENXIO;
> >>>
> >>> /* Enable management port */
> >>> macb_writel(bp, NCR, MACB_BIT(MPE));
> >>> @@ -446,33 +497,10 @@ static int macb_mii_init(struct macb *bp)
> >>> dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
> >>>
> >>> np = bp->pdev->dev.of_node;
> >>> - if (np) {
> >>> - /* try dt phy registration */
> >>> - err = of_mdiobus_register(bp->mii_bus, np);
> >>> -
> >>> - /* fallback to standard phy registration if no phy were
> >>> - * found during dt phy registration
> >>> - */
> >>> - if (!err && !phy_find_first(bp->mii_bus)) {
> >>> - for (i = 0; i < PHY_MAX_ADDR; i++) {
> >>> - struct phy_device *phydev;
> >>> -
> >>> - phydev = mdiobus_scan(bp->mii_bus, i);
> >>> - if (IS_ERR(phydev)) {
> >>> - err = PTR_ERR(phydev);
> >>> - break;
> >>> - }
> >>> - }
> >>> -
> >>> - if (err)
> >>> - goto err_out_unregister_bus;
> >>> - }
> >>> - } else {
> >>> - if (pdata)
> >>> - bp->mii_bus->phy_mask = pdata->phy_mask;
> >>> -
> >>> - err = mdiobus_register(bp->mii_bus);
> >>> - }
> >>> + if (np)
> >>> + err = macb_mii_of_init(bp, np);
> >>> + else
> >>> + err = macb_mii_pdata_init(bp, pdata);
> >>>
> >>> if (err)
> >>> goto err_out_free_mdiobus;
> >>
> >> I'm okay with this. Thanks for having taken the initiative to implement it.
> >
> > Unfortunately, I don't think it's going to be as straightforward
> > as I originally thought. Still doable, but more complicated.
> >
> > In particular, the macb bindings allow for a user to specify a
> > 'reset-gpios' property _at the PHY_ level, which is consumed by the
> > macb to adjust the PHY reset state on remove.
>
> In fact, not just on remove, anytime there is an opportunity to save
> power (interface down, closed) and putting the PHY into reset is usually
> guaranteed to be saving more power than e.g: a BMCR power down.
I can understand how that might have been a long term goal of managing a
reset GPIO in general, however as it stands in the macb driver the only
callsite where the reset gpio is tweaked macb_remove().
> > My question is: why is the PHY reset GPIO management not the
> > responsibility of the PHY driver/core itself?
>
> Well, this is actually being worked on at the moment by Sergei, since
> there is not necessarily a reason why PHYLIB can't deal with that:
>
> https://lkml.org/lkml/2016/4/28/831
Cool, thanks. I was about to see about implementing this...but since
it's already been done, I'll rebase my set on Sergei's changes.
Thanks,
Josh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCHv2 bluetooth-next 08/10] ipv6: export ndisc functions
From: Hannes Frederic Sowa @ 2016-05-02 19:39 UTC (permalink / raw)
To: Alexander Aring, linux-wpan
Cc: kernel, marcel, jukka.rissanen, stefan, mcr, werner,
linux-bluetooth, netdev, David S . Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1461140382-4784-9-git-send-email-aar@pengutronix.de>
On 20.04.2016 10:19, Alexander Aring wrote:
> This patch exports some neighbour discovery functions which can be used
> by 6lowpan neighbour discovery ops functionality then.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Alexander Aring <aar@pengutronix.de>
> ---
> include/net/ndisc.h | 16 ++++++++++++++++
> net/ipv6/addrconf.c | 1 +
> net/ipv6/ndisc.c | 28 ++++++++++------------------
> 3 files changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/include/net/ndisc.h b/include/net/ndisc.h
> index 14ed016..35a4396 100644
> --- a/include/net/ndisc.h
> +++ b/include/net/ndisc.h
> @@ -53,6 +53,15 @@ enum {
>
> #include <net/neighbour.h>
>
> +/* Set to 3 to get tracing... */
> +#define ND_DEBUG 1
> +
> +#define ND_PRINTK(val, level, fmt, ...) \
> +do { \
> + if (val <= ND_DEBUG) \
> + net_##level##_ratelimited(fmt, ##__VA_ARGS__); \
> +} while (0)
> +
If the debug messages are well thought out, I think we could install
them always on debug level.
There are valid users now, so
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH next-next 0/7] net: Cleanup IPv6 ip tunnels
From: Alexander Duyck @ 2016-05-02 19:42 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S379KxUkLRaE70AtaPgM8NqEieavd1+hcX=Z4Jfdn=CFDw@mail.gmail.com>
On Mon, May 2, 2016 at 12:32 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, Apr 29, 2016 at 6:00 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, Apr 29, 2016 at 5:12 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> The IPv6 tunnel code is very different from IPv4 code. There is a lot
>>> of redundancy with the IPv4 code, particularly in the GRE tunneling.
>>>
>>> This patch set cleans up the tunnel code to make the IPv6 code look
>>> more like the IPv4 code and use common functions between the two
>>> stacks where possible.
>>>
>>> This work should make it easier to maintain and extend the IPv6 ip
>>> tunnels.
>>>
>>> Items in this patch set:
>>> - Cleanup IPv6 tunnel receive path (ip6_tnl_rcv). Includes using
>>> gro_cells and exporting ip6_tnl_rcv so the ip6_gre can call it
>>> - Move GRE functions to common header file (tx functions) or
>>> gre_demux.c (rx functions like gre_parse_header)
>>> - Call common GRE functions from IPv6 GRE
>>> - Create ip6_tnl_xmit (to be like ip_tunnel_xmit)
>>>
>>> Tested:
>>> Ran super_netperf tests for TCP_RR and TCP_STREAM for:
>>> - IPv4 over gre, gretap, gre6, gre6tap
>>> - IPv6 over gre, gretap, gre6, gre6tap
>>> - ipip
>>> - ip6ip6
>>> - ipip/gue
>>> - IPv6 over gre/gue
>>> - IPv4 over gre/gue
>>
>> You should probably add 2 additional test cases. One for IPv4 GRE/GUE
>> w/ checksum on the GRE header, and same for IPv6. It was broken
>> previously in terms of offloads so we need to make sure we don't
>> introduce a regression and break it again.
>>
> Hi Alexander,
>
> I did test GRE/GUE with checksum and remcsum for IPv4, that works okay.
>
> Support for GUE with IPv6 is in the next patch set I am working on.
>
> Thanks,
> Tom
Just so it is clear I am talking about having a checksum in the GRE
header, not the GUE header. If there is a GRE checksum present we
have to force software segmentation since we don't have any means of
pointing to the header in a way that is meaningful for hardware. As
long as we don't see any regressions I am good with these changes.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd
From: Hannes Frederic Sowa @ 2016-05-02 19:52 UTC (permalink / raw)
To: Marcel Holtmann, Alexander Aring, David S. Miller
Cc: linux-wpan-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Jukka Rissanen, Stefan Schmidt, mcr-SWp7JaYWvAQV+D8aMU/kSg,
Werner Almesberger, Linux Bluetooth, Network Development,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <D212A5BF-A414-403B-A409-1F8C2D279883-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On 02.05.2016 19:25, Marcel Holtmann wrote:
> Hi Dave,
>
>> this patch series introduces a layer for IPv6 neighbour discovery. At first
>> it introduce the "ndisc_ops" to run a different handling for recv/send of
>> NA/NS messages. The use case for such ndisc operation is RFC 6775 [0].
>> Which describes a different neighbour discovery handling for 6LoWPAN networks.
>>
>> I didn't implement RFC 6775 in this patch series, but introduce callback
>> structure for replace different functions in ndisc implementation might be
>> the right direction.
>>
>> Another use case would be RFC 7400 [1] which describes a new option field to
>> getting capabilities of 6LoWPAN next header compression methods.
>>
>> What I implemented is a necessary functionality to handle short address for
>> 802.15.4 6LoWPAN networks. The L2-Layer "802.15.4" can have two different
>> link-layer addresses which can be used mixed at the same time inside 802.15.4
>> networks. To deal with such behaviour in ndisc, it is defined at RFC 4944 [2].
>> The bad news is, that I saw different handling of such handling. What Linux
>> will do is to add two source/target address information option fields, each
>> with different length, if short address is valid (can also not be given).
>> Example:
>>
>> - WPAN interface address settings
>> - extended addr (must always be there)
>> - short addr (0xfffe or 0xffff -> invalid)
>>
>> Will add an extended addr to source/target address information option field.
>> If short addr is in some valid range, then both address will be added to
>> the option fields. Indicated are these different address types by the length
>> field (extended -> length=2, short -> length=1), according to [1].
>>
>> The tested 6LoWPAN implementation (RIOT-OS) allows only one source/target
>> option field which is short XOR extended, otherwise it will be dropped.
>> There is some lack of information there [2] and I don't know how do deal with
>> it right, maybe we need to update the implementation there if it's really
>> wrong.
>>
>> To save such information for each neighbour we use the already implemented
>> neighbour private data which some casting strategy for 6LoWPAN and 6LoWPAN
>> link-layer specific data e.g. 802.15.4 short address handling.
>>
>> Additional I implemented to add 6CO to the is_useropt callback in case of
>> 6LoWPAN interface. The 6CO option will currently parsed in userspace which
>> are placed in RA-Messages.
>>
>> The ndisc_ops are not finished yet, of course we need handling for RS messages
>> to place the 802.15.4 short address there as well and then also processing
>> of RA messages for the 802.15.4 SLLAO option field.
>>
>> - Alex
>>
>> [0] https://tools.ietf.org/html/rfc6775
>> [1] https://tools.ietf.org/html/rfc7400#section-3.3
>> [2] https://tools.ietf.org/html/rfc4944#section-8
>>
>> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> Cc: Alexey Kuznetsov <kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org>
>> Cc: James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
>> Cc: Hideaki YOSHIFUJI <yoshfuji-VfPWfsRibaP+Ru+s062T9g@public.gmane.org>
>> Cc: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
>>
>> changes since v2:
>> - replace #ifdef CONFIG_IPV6 to #if IS_ENABLED(...)
>> - replace #ifdef CONFIG_IEEE802154... to #if IS_ENABLED(...)
>> - add more #if IS_ENABLED(CONFIG_IPV6) in ndisc.h
>>
>> Alexander Aring (10):
>> 6lowpan: add private neighbour data
>> 6lowpan: add 802.15.4 short addr slaac
>> 6lowpan: remove ipv6 module request
>> ndisc: add addr_len parameter to ndisc_opt_addr_space
>> ndisc: add addr_len parameter to ndisc_opt_addr_data
>> ndisc: add addr_len parameter to ndisc_fill_addr_option
>> ipv6: introduce neighbour discovery ops
>> ipv6: export ndisc functions
>> 6lowpan: introduce 6lowpan-nd
>> 6lowpan: add support for 802.15.4 short addr handling
>>
>> include/linux/netdevice.h | 6 +-
>> include/net/6lowpan.h | 24 ++
>> include/net/addrconf.h | 3 +
>> include/net/ndisc.h | 124 ++++++++-
>> net/6lowpan/6lowpan_i.h | 2 +
>> net/6lowpan/Makefile | 2 +-
>> net/6lowpan/core.c | 50 +++-
>> net/6lowpan/iphc.c | 167 +++++++++--
>> net/6lowpan/ndisc.c | 633 ++++++++++++++++++++++++++++++++++++++++++
>> net/bluetooth/6lowpan.c | 2 +
>> net/ieee802154/6lowpan/core.c | 12 +
>> net/ieee802154/6lowpan/tx.c | 107 ++++---
>> net/ipv6/addrconf.c | 7 +-
>> net/ipv6/ndisc.c | 132 +++++----
>> net/ipv6/route.c | 4 +-
>> 15 files changed, 1117 insertions(+), 158 deletions(-)
>> create mode 100644 net/6lowpan/ndisc.c
>
> is there a chance that we get input into this patch set? I wonder also if it would be acceptable to take this through bluetooth-next or should it better go straight into net-next?
My proposal would be that the IPv6 patches go via net-next to reduce
merge conflicts with maybe upcoming changes. If they are split up, they
seem very much self contained and easy to review. The rest seems to be
also very much self contained and can go in via bluetooth-next, then.
What do you think?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: SOCKWQ_ASYNC_NOSPACE optimizations
From: Eric Dumazet @ 2016-05-02 20:23 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Eric Dumazet, David S . Miller, netdev, eladr, idosch
In-Reply-To: <20160502191229.GA1946@nanopsycho.orion>
On Mon, 2016-05-02 at 21:12 +0200, Jiri Pirko wrote:
> Mon, May 02, 2016 at 06:22:18PM CEST, eric.dumazet@gmail.com wrote:
> >On Mon, 2016-05-02 at 18:16 +0200, Jiri Pirko wrote:
> >> Mon, Apr 25, 2016 at 07:39:32PM CEST, edumazet@google.com wrote:
> >> >SOCKWQ_ASYNC_NOSPACE is tested in sock_wake_async()
> >> >so that a SIGIO signal is sent when needed.
> >> >
> >> >tcp_sendmsg() clears the bit.
> >> >tcp_poll() sets the bit when stream is not writeable.
> >> >
> >> >We can avoid two atomic operations by first checking if socket
> >> >is actually interested in the FASYNC business (most sockets in
> >> >real applications do not use AIO, but select()/poll()/epoll())
> >> >
> >> >This also removes one cache line miss to access sk->sk_wq->flags
> >> >in tcp_sendmsg()
> >> >
> >> >Signed-off-by: Eric Dumazet <edumazet@google.com>
> >>
> >> I just bisected down to this. This is causing a regression for me when
> >> my nfs mount becomes stuck. I can easily reproduce this if you need to
> >> test the fix.
> >
> >What do you mean by 'when nfs mount becomes stuck' ?
> >
> >Is this patch making nfs not functional , or does it make recovery from
> >some nfs error bad ?
>
> I can mount nfs on the host. But when I do something (compile a kernel
> module in my case), it gets stuck. Then I cannot even ssh to the machine.
> No messages in dmesg. I didn't debug it any further. I just bisected and
> verified that this patch caused this behaviour.
Interesting.
It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC
even if it is not actually using fasync_list
Could you try this quick hack to check if this is the right way ?
Thanks !
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index a6c68dc086af83233ee315642638f4a1990ee622..b90c5397b5e137c6cc8accad6eebe2b876363d4e 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1950,6 +1950,7 @@ static int xs_local_finish_connecting(struct rpc_xprt *xprt,
sk->sk_user_data = xprt;
sk->sk_data_ready = xs_data_ready;
sk->sk_write_space = xs_udp_write_space;
+ sock_set_flag(sk, SOCK_FASYNC);
sk->sk_error_report = xs_error_report;
sk->sk_allocation = GFP_NOIO;
@@ -2136,6 +2137,7 @@ static void xs_udp_finish_connecting(struct rpc_xprt *xprt, struct socket *sock)
sk->sk_user_data = xprt;
sk->sk_data_ready = xs_data_ready;
sk->sk_write_space = xs_udp_write_space;
+ sock_set_flag(sk, SOCK_FASYNC);
sk->sk_allocation = GFP_NOIO;
xprt_set_connected(xprt);
@@ -2237,6 +2239,7 @@ static int xs_tcp_finish_connecting(struct rpc_xprt *xprt, struct socket *sock)
sk->sk_data_ready = xs_tcp_data_ready;
sk->sk_state_change = xs_tcp_state_change;
sk->sk_write_space = xs_tcp_write_space;
+ sock_set_flag(sk, SOCK_FASYNC);
sk->sk_error_report = xs_error_report;
sk->sk_allocation = GFP_NOIO;
^ permalink raw reply related
* NULL dereference on v4.1.x while enabling VF
From: William Dauchy @ 2016-05-02 20:25 UTC (permalink / raw)
To: NETDEV, intel-wired-lan; +Cc: Emil Tantilov, Jeff Kirsher, Alex Duyck
Hello,
I am getting a NULL dereference on v4.1.x while enabling VF on a ixgbe
( Intel Corporation 82599ES 10-Gigabit) card during boot.
It seems to be related to a race since I don't have the issue if I
test it a few seconds after boot. I had the same issue while testing
on v4.5.x
What can I do to help debug the issue?
ip link set dev eth0 up
echo 32 > /sys/class/net/eth0/device/sriov_numvfs
part of the dmesg:
ixgbe 0000:82:00.1: removed PHC on eth1
ixgbe 0000:82:00.1: Multiqueue Enabled: Rx Queue count = 2, Tx Queue count = 2
ixgbe 0000:82:00.1: registered PHC device on eth1
ixgbe 0000:82:00.1 eth1: detected SFP+: 4
ixgbe 0000:82:00.1 eth1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
ixgbevf: Could not enable Tx Queue 0
ixgbevf: Could not enable Tx Queue 1
8021q: adding VLAN 0 to HW filter on device eth2
ixgbe 0000:82:00.0 eth0: VF Reset msg received from vf 0
ixgbe 0000:82:00.0: VF 0 has no MAC address assigned, you may have to
assign one manually
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
ixgbevf: Could not enable Tx Queue 0
ixgbevf: Could not enable Tx Queue 1
IP: [<ffffffff813d3873>] ixgbevf_alloc_rx_buffers+0x53/0x170
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 8 PID: 1034 Comm: kworker/8:1 Tainted: G W 4.1.23 #1
Workqueue: events ixgbevf_service_task
task: ffff882021558000 ti: ffff882021554000 task.ti: ffff882021554000
RIP: 0010:[<ffffffff813d3873>] [<ffffffff813d3873>]
ixgbevf_alloc_rx_buffers+0x53/0x170
RSP: 0018:ffff882021557c58 EFLAGS: 00010246
RAX: 0000000000000200 RBX: ffff88201ccc09c0 RCX: 0000000000000000
RDX: ffffc9000e860000 RSI: 00000000000001ff RDI: ffff88201ccc09c0
RBP: ffff882021557c98 R08: 0000000000000001 R09: 0000000000000001
R10: ffff882021558000 R11: 000000000000017e R12: 0000000000000000
R13: 00000000fffffe00 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88207fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000001a08000 CR4: 00000000001406e0
Stack:
ffff88201d630940 01ff00000000000a ffff882021557c78 ffff88201d630c28
ffff88201d630940 0000000000000009 ffff88201ccc09c0 0000000000000000
ffff882021557d18 ffffffff813d54b8 0000102800001028 0000000000000000
Call Trace:
[<ffffffff813d54b8>] ixgbevf_configure+0x50d/0x54e
[<ffffffff813d6a11>] ? ixgbevf_down+0x2ba/0x2cb
[<ffffffff813d6687>] ixgbevf_up+0x13/0x1f
[<ffffffff813d6a85>] ixgbevf_reinit_locked+0x63/0x6c
[<ffffffff813d76c9>] ixgbevf_service_task+0xe5/0x2dc
[<ffffffff810743b7>] process_one_work+0x275/0x4f2
[<ffffffff81074ae1>] worker_thread+0x1f5/0x2a9
[<ffffffff810748ec>] ? rescuer_thread+0x289/0x289
[<ffffffff810748ec>] ? rescuer_thread+0x289/0x289
[<ffffffff81079775>] kthread+0xc5/0xcd
[<ffffffff81577e9f>] ? _raw_spin_unlock_irq+0x2d/0x4c
[<ffffffff810796b0>] ? __kthread_parkme+0x87/0x87
[<ffffffff81578a82>] ret_from_fork+0x42/0x70
[<ffffffff810796b0>] ? __kthread_parkme+0x87/0x87
Code: 0f 84 33 01 00 00 44 0f b7 67 2e 48 89 fb 0f b7 47 2c 4d 89 e5
4d 89 e6 4d 6b e4 18 49 c1 e6 04 4c 03 77 18 41 29 c5 4c 03 67 38 <49>
83 7c 24 08 00 0f 85 9e 00 00 00 65 8b 05 2a dc c3 7e 48 98
RIP [<ffffffff813d3873>] ixgbevf_alloc_rx_buffers+0x53/0x170
RSP <ffff882021557c58>
CR2: 0000000000000008
---[ end trace 6e4d9e7fa97d4fca ]---
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:21
in_atomic(): 0, irqs_disabled(): 1, pid: 1034, name: kworker/8:1
INFO: lockdep is turned off.
irq event stamp: 43238
hardirqs last enabled at (43237): [<ffffffff81577efd>]
_raw_spin_unlock_irqrestore+0x3f/0x60
hardirqs last disabled at (43238): [ 41.225859] 8021q: adding VLAN 0
to HW filter on device eth3
[<ffffffff8157a4b3>] error_sti+0x5/0x6
Thanks,
--
William
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: SOCKWQ_ASYNC_NOSPACE optimizations
From: David Miller @ 2016-05-02 20:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: jiri, edumazet, netdev, eladr, idosch
In-Reply-To: <1462220607.5535.273.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 May 2016 13:23:27 -0700
> It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC
> even if it is not actually using fasync_list
>
> Could you try this quick hack to check if this is the right way ?
Indeed, it tests the ASYNC bit without enabling FASYNC.
There are three other places that do this: macvtap, tun, dlm lowcomms.
^ permalink raw reply
* [PATCH net v2 2/2] udp_offload: Set encapsulation before inner completes.
From: Jarno Rajahalme @ 2016-05-02 20:39 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: jesse, jarno
In-Reply-To: <1462221590-14309-1-git-send-email-jarno@ovn.org>
UDP tunnel segmentation code relies on the inner offsets being set for
an UDP tunnel GSO packet, but the inner *_complete() functions will
set the inner offsets only if 'encapsulation' is set before calling
them. Currently, udp_gro_complete() sets 'encapsulation' only after
the inner *_complete() functions are done. This causes the inner
offsets having invalid values after udp_gro_complete() returns, which
in turn will make it impossible to properly segment the packet in case
it needs to be forwarded, which would be visible to the user either as
invalid packets being sent or as packet loss.
This patch fixes this by setting skb's 'encapsulation' before calling
into the inner complete functions, and by removing the setting of the
inner_mac_header in udp_gro_complete(). The inner complete now
functions set the inner_mac_header, so it need not be done here.
Furthermore, it was wrongly set to the beginning of the UDP tunnel
header rather than the inner MAC header.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
---
net/ipv4/udp_offload.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 0ed2daf..e330c0e 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -399,6 +399,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
uh->len = newlen;
+ /* Set encapsulation before calling into inner gro_complete() functions
+ * to make them set up the inner offsets.
+ */
+ skb->encapsulation = 1;
+
rcu_read_lock();
uo_priv = rcu_dereference(udp_offload_base);
@@ -421,9 +426,6 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
if (skb->remcsum_offload)
skb_shinfo(skb)->gso_type |= SKB_GSO_TUNNEL_REMCSUM;
- skb->encapsulation = 1;
- skb_set_inner_mac_header(skb, nhoff + sizeof(struct udphdr));
-
return err;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 1/2] udp_tunnel: Remove redundant udp_tunnel_gro_complete().
From: Jarno Rajahalme @ 2016-05-02 20:39 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: jesse, jarno
The setting of the UDP tunnel GSO type is already performed by
udp[46]_gro_complete().
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
---
drivers/net/geneve.c | 2 --
drivers/net/vxlan.c | 2 --
include/net/udp_tunnel.h | 9 ---------
net/ipv4/fou.c | 2 --
4 files changed, 15 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index bc16889..98f1224 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -504,8 +504,6 @@ static int geneve_gro_complete(struct sk_buff *skb, int nhoff,
int gh_len;
int err = -ENOSYS;
- udp_tunnel_gro_complete(skb, nhoff);
-
gh = (struct genevehdr *)(skb->data + nhoff);
gh_len = geneve_hlen(gh);
type = gh->proto_type;
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 1c0fa36..dd2d032 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -616,8 +616,6 @@ out:
static int vxlan_gro_complete(struct sk_buff *skb, int nhoff,
struct udp_offload *uoff)
{
- udp_tunnel_gro_complete(skb, nhoff);
-
return eth_gro_complete(skb, nhoff + sizeof(struct vxlanhdr));
}
diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index b831140..a114024 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -106,15 +106,6 @@ static inline struct sk_buff *udp_tunnel_handle_offloads(struct sk_buff *skb,
return iptunnel_handle_offloads(skb, type);
}
-static inline void udp_tunnel_gro_complete(struct sk_buff *skb, int nhoff)
-{
- struct udphdr *uh;
-
- uh = (struct udphdr *)(skb->data + nhoff - sizeof(struct udphdr));
- skb_shinfo(skb)->gso_type |= uh->check ?
- SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
-}
-
static inline void udp_tunnel_encap_enable(struct socket *sock)
{
#if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index a39068b..305d9ac 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -228,8 +228,6 @@ static int fou_gro_complete(struct sk_buff *skb, int nhoff,
int err = -ENOSYS;
const struct net_offload **offloads;
- udp_tunnel_gro_complete(skb, nhoff);
-
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[proto]);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: SOCKWQ_ASYNC_NOSPACE optimizations
From: Jiri Pirko @ 2016-05-02 20:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, David S . Miller, netdev, eladr, idosch
In-Reply-To: <1462220607.5535.273.camel@edumazet-glaptop3.roam.corp.google.com>
Mon, May 02, 2016 at 10:23:27PM CEST, eric.dumazet@gmail.com wrote:
>On Mon, 2016-05-02 at 21:12 +0200, Jiri Pirko wrote:
>> Mon, May 02, 2016 at 06:22:18PM CEST, eric.dumazet@gmail.com wrote:
>> >On Mon, 2016-05-02 at 18:16 +0200, Jiri Pirko wrote:
>> >> Mon, Apr 25, 2016 at 07:39:32PM CEST, edumazet@google.com wrote:
>> >> >SOCKWQ_ASYNC_NOSPACE is tested in sock_wake_async()
>> >> >so that a SIGIO signal is sent when needed.
>> >> >
>> >> >tcp_sendmsg() clears the bit.
>> >> >tcp_poll() sets the bit when stream is not writeable.
>> >> >
>> >> >We can avoid two atomic operations by first checking if socket
>> >> >is actually interested in the FASYNC business (most sockets in
>> >> >real applications do not use AIO, but select()/poll()/epoll())
>> >> >
>> >> >This also removes one cache line miss to access sk->sk_wq->flags
>> >> >in tcp_sendmsg()
>> >> >
>> >> >Signed-off-by: Eric Dumazet <edumazet@google.com>
>> >>
>> >> I just bisected down to this. This is causing a regression for me when
>> >> my nfs mount becomes stuck. I can easily reproduce this if you need to
>> >> test the fix.
>> >
>> >What do you mean by 'when nfs mount becomes stuck' ?
>> >
>> >Is this patch making nfs not functional , or does it make recovery from
>> >some nfs error bad ?
>>
>> I can mount nfs on the host. But when I do something (compile a kernel
>> module in my case), it gets stuck. Then I cannot even ssh to the machine.
>> No messages in dmesg. I didn't debug it any further. I just bisected and
>> verified that this patch caused this behaviour.
>
>Interesting.
>
>It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC
>even if it is not actually using fasync_list
>
>Could you try this quick hack to check if this is the right way ?
Yep, works, I do not see the issue with this patch anymore. Thanks.
>
>Thanks !
>
>diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
>index a6c68dc086af83233ee315642638f4a1990ee622..b90c5397b5e137c6cc8accad6eebe2b876363d4e 100644
>--- a/net/sunrpc/xprtsock.c
>+++ b/net/sunrpc/xprtsock.c
>@@ -1950,6 +1950,7 @@ static int xs_local_finish_connecting(struct rpc_xprt *xprt,
> sk->sk_user_data = xprt;
> sk->sk_data_ready = xs_data_ready;
> sk->sk_write_space = xs_udp_write_space;
>+ sock_set_flag(sk, SOCK_FASYNC);
> sk->sk_error_report = xs_error_report;
> sk->sk_allocation = GFP_NOIO;
>
>@@ -2136,6 +2137,7 @@ static void xs_udp_finish_connecting(struct rpc_xprt *xprt, struct socket *sock)
> sk->sk_user_data = xprt;
> sk->sk_data_ready = xs_data_ready;
> sk->sk_write_space = xs_udp_write_space;
>+ sock_set_flag(sk, SOCK_FASYNC);
> sk->sk_allocation = GFP_NOIO;
>
> xprt_set_connected(xprt);
>@@ -2237,6 +2239,7 @@ static int xs_tcp_finish_connecting(struct rpc_xprt *xprt, struct socket *sock)
> sk->sk_data_ready = xs_tcp_data_ready;
> sk->sk_state_change = xs_tcp_state_change;
> sk->sk_write_space = xs_tcp_write_space;
>+ sock_set_flag(sk, SOCK_FASYNC);
> sk->sk_error_report = xs_error_report;
> sk->sk_allocation = GFP_NOIO;
>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/3] drivers: net: xgene: fix: Get channel number from device binding
From: David Miller @ 2016-05-02 20:48 UTC (permalink / raw)
To: isubramanian; +Cc: netdev, devicetree, linux-arm-kernel, patches
In-Reply-To: <1461953415-9741-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Fri, 29 Apr 2016 11:10:12 -0700
> This patch set adds 'channel' property to get ethernet to CPU channel number,
> thus decoupling the Linux driver from static resource selection.
>
> v2: Address review comments from v1
> - removed irq reference from Linux driver
> - added 'channel' property to get ethernet to CPU channel number
>
> v1:
> - Initial version
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 2/3] udp_offload: Set encapsulation before inner completes.
From: Jarno Rajahalme @ 2016-05-02 21:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers, Jesse Gross
In-Reply-To: <CALx6S35N7PtaERFCs27X5GuqUZKYkPFeG8ZQB=0uGpydw+ABEg@mail.gmail.com>
> On Apr 29, 2016, at 6:42 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> On Fri, Apr 29, 2016 at 3:28 PM, Jarno Rajahalme <jarno@ovn.org> wrote:
>> UDP tunnel segmentation code relies on the inner offsets being set for
>> an UDP tunnel GSO packet. The inner *_complete() functions will set
>> the inner offsets only if the encapsulation is set before calling
>> them, but udp_gro_complete() set it only after the inner *_complete()
>> functions were done.
>>
>> Also, remove the setting of the inner_mac_header in udp_gro_complete()
>> as it was wrongly set to the beginning of the UDP tunnel header rather
>> than the inner MAC header.
>>
> How did you test this? Do you have a test case for the problem?
>
I faced this problem when developing UDP tunnel offloads for virtio_net. Basically the GRO of encapsulated packets on the rx side should produce the same inner offsets that the original encapsulation did on the tx side. __skb_udp_tunnel_segment() has this line:
int tnl_hlen = skb_inner_mac_header(skb) - skb_transport_header(skb);
which is intended to capture both the UDP header and the tunneling protocol header (e.g., UDP + variable length GENEVE header). So, if the inner MAC header is incorrectly set the segmentation would not work as expected.
> The general problem is that skb->encapsulation is the indicator that
> the inner offsets are valid, but there are many instances where we set
> skb->encapsulation independently of setting the inner headers. It
> would be nice if setting the flag and setting the inner headers were
> somehow unified.
>
Agree, it was rather tedious to trace the call flow to figure out what is going on.
Jarno
> Thanks,
> Tom
>
>> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
>> ---
>> net/ipv4/udp_offload.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index 0ed2daf..e330c0e 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -399,6 +399,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>>
>> uh->len = newlen;
>>
>> + /* Set encapsulation before calling into inner gro_complete() functions
>> + * to make them set up the inner offsets.
>> + */
>> + skb->encapsulation = 1;
>> +
>> rcu_read_lock();
>>
>> uo_priv = rcu_dereference(udp_offload_base);
>> @@ -421,9 +426,6 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>> if (skb->remcsum_offload)
>> skb_shinfo(skb)->gso_type |= SKB_GSO_TUNNEL_REMCSUM;
>>
>> - skb->encapsulation = 1;
>> - skb_set_inner_mac_header(skb, nhoff + sizeof(struct udphdr));
>> -
>> return err;
>> }
>>
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: SOCKWQ_ASYNC_NOSPACE optimizations
From: Eric Dumazet @ 2016-05-02 20:55 UTC (permalink / raw)
To: David Miller; +Cc: jiri, edumazet, netdev, eladr, idosch
In-Reply-To: <20160502.163140.11281931277716285.davem@davemloft.net>
On Mon, 2016-05-02 at 16:31 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 02 May 2016 13:23:27 -0700
>
> > It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC
> > even if it is not actually using fasync_list
> >
> > Could you try this quick hack to check if this is the right way ?
>
> Indeed, it tests the ASYNC bit without enabling FASYNC.
>
> There are three other places that do this: macvtap, tun, dlm lowcomms.
Yes, although macvtap and tun have a private usage of this bit.
When the flag was moved (commit ceb5d58b217098a657f3850b7a2640f995032e62
"net: fix sock_wake_async() rcu protection"), I did not change the code
in these drivers. And apparently nobody complained (linux-4.4)
drivers/net/macvtap.c:501: !test_and_clear_bit(SOCKWQ_ASYNC_NOSPACE, &sk->sk_socket->flags))
drivers/net/macvtap.c:588: (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags) &&
drivers/net/tun.c:1111: (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &sk->sk_socket->flags) &&
drivers/net/tun.c:1576: if (!test_and_clear_bit(SOCKWQ_ASYNC_NOSPACE, &sk->sk_socket->flags))
fs/dlm/lowcomms.c probably needs a fix.
^ permalink raw reply
* Re: [PATCH net 2/3] udp_offload: Set encapsulation before inner completes.
From: Jarno Rajahalme @ 2016-05-02 21:21 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Netdev, Jesse Gross
In-Reply-To: <CAKgT0UcGCgRt5dpG2Y0a6sBar1KF1DkHxdhMbCOYV6qj15D50A@mail.gmail.com>
> On Apr 29, 2016, at 8:46 PM, Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
> On Fri, Apr 29, 2016 at 3:28 PM, Jarno Rajahalme <jarno@ovn.org> wrote:
>> UDP tunnel segmentation code relies on the inner offsets being set for
>> an UDP tunnel GSO packet. The inner *_complete() functions will set
>> the inner offsets only if the encapsulation is set before calling
>> them, but udp_gro_complete() set it only after the inner *_complete()
>> functions were done.
>>
>> Also, remove the setting of the inner_mac_header in udp_gro_complete()
>> as it was wrongly set to the beginning of the UDP tunnel header rather
>> than the inner MAC header.
>>
>> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
>> ---
>> net/ipv4/udp_offload.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index 0ed2daf..e330c0e 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -399,6 +399,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>>
>> uh->len = newlen;
>>
>> + /* Set encapsulation before calling into inner gro_complete() functions
>> + * to make them set up the inner offsets.
>> + */
>> + skb->encapsulation = 1;
>> +
>> rcu_read_lock();
>>
>> uo_priv = rcu_dereference(udp_offload_base);
>> @@ -421,9 +426,6 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>> if (skb->remcsum_offload)
>> skb_shinfo(skb)->gso_type |= SKB_GSO_TUNNEL_REMCSUM;
>>
>> - skb->encapsulation = 1;
>> - skb_set_inner_mac_header(skb, nhoff + sizeof(struct udphdr));
>> -
>> return err;
>> }
>>
>> --
>> 2.7.4
>>
>
> So looking over this I think this patch is just a band-aid and it
> isn't really fixing much of anything. For example I cannot see where
It fixes the immediate bug/problem that segmentation of GRO UDP tunnel packet fails due to incorrectly set inner MAC offset and/or missing inner network offset.
> the inner transport offset is ever set. From what I can tell it never
> is.
>
inner transport offset is set in validate_xmit_skb(), but you are right, it is not set by the GRO complete code path. AFAIK no-one uses it before reaching validate_xmit_skb(), though. The documentation in (net-next) Documentation/networking/segmentation-offloads.txt could be fixed by removing the inner transport header from UDP/GRE tunnel case, as it is not used by either the GRE or UDP tunnel code.
Jarno
> What we probably need to do is the same thing we currently do in the
> transmit path itself. We need to record all the headers on the way up
> so that we end up with the network and transport headers matching the
> inner headers, then when we complete the inner-most tunnel we set the
> inner headers and set skb->encapsulation. Then on the way down we
> start overwriting the outer header offsets when skb->encapsulation is
> set. That way we don't have to worry about screwing things up for
> headers like GRE/GUE because the GRE can write the inner header
> offsets, set skb->encapsulation, and then we only overwrite the outer
> headers all the way down because with skb->encapsulation set we know
> we are only dealing with outer headers because the inner header values
> have been written.
>
> - Alex
^ permalink raw reply
* RE: [Intel-wired-lan] NULL dereference on v4.1.x while enabling VF
From: Skidmore, Donald C @ 2016-05-02 21:33 UTC (permalink / raw)
To: William Dauchy, NETDEV, intel-wired-lan@lists.osuosl.org; +Cc: Alex Duyck
In-Reply-To: <CAJ75kXZV32hLzYY-dynYAj6NHm2xNoq89inmSSbqUyxPvUazEw@mail.gmail.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On
> Behalf Of William Dauchy
> Sent: Monday, May 02, 2016 1:26 PM
> To: NETDEV <netdev@vger.kernel.org>; intel-wired-lan@lists.osuosl.org
> Cc: Alex Duyck <aduyck@mirantis.com>
> Subject: [Intel-wired-lan] NULL dereference on v4.1.x while enabling VF
>
> Hello,
>
> I am getting a NULL dereference on v4.1.x while enabling VF on a ixgbe (
> Intel Corporation 82599ES 10-Gigabit) card during boot.
> It seems to be related to a race since I don't have the issue if I test it a few
> seconds after boot. I had the same issue while testing on v4.5.x What can I
> do to help debug the issue?
>
> ip link set dev eth0 up
> echo 32 > /sys/class/net/eth0/device/sriov_numvfs
Hey William,
Thanks for reporting the dereference. Could you provide a little more detail on how you created this issue? Are you just running the two commands (ip, sriov_numvfs) in some rc script and if you put a few second sleep in front of it you don't see the failure?
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [Bug 117521] New: BUG: unable to handle kernel paging request at 000001a400015ff4
From: Andrew Morton @ 2016-05-02 21:48 UTC (permalink / raw)
To: gbalasun; +Cc: bugzilla-daemon, Jon Maloy, Ying Xue, netdev, tipc-discussion
In-Reply-To: <bug-117521-27@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
Thanks. It's probably a TIPC issue.
On Mon, 02 May 2016 16:44:18 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=117521
>
> Bug ID: 117521
> Summary: BUG: unable to handle kernel paging request at
> 000001a400015ff4
> Product: Memory Management
> Version: 2.5
> Kernel Version: 4.4.0
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Other
> Assignee: akpm@linux-foundation.org
> Reporter: gbalasun@gmail.com
> Regression: No
>
> [ 65.954959] sm-msp-queue[1279]: unable to qualify my own domain name
> (dcsx5testslot3) -- using short name
> [ 632.098785] perf interrupt took too long (2505 > 2500), lowering
> kernel.perf_event_max_sample_rate to 50000
> [ 5880.428123] perf interrupt took too long (5585 > 5000), lowering
> kernel.perf_event_max_sample_rate to 25000
> [17934.014969] CE: hpet increased min_delta_ns to 20115 nsec
> [38956.721789] CE: hpet4 increased min_delta_ns to 20115 nsec
> [46927.872827] hrtimer: interrupt took 63361 ns
> [101662.241093] CE: hpet2 increased min_delta_ns to 20115 nsec
> [245973.044600] CE: hpet6 increased min_delta_ns to 20115 nsec
> [368639.565040] show_signal_msg: 6 callbacks suppressed
> [375832.498126] BUG: unable to handle kernel paging request at 000001a400015ff4
> [375832.505300] IP: [<ffffffff810c3566>] queued_spin_lock_slowpath+0xe6/0x160
> [375832.512394] PGD 0
> [375832.514657] Oops: 0002 [#1] SMP
> [375832.518306] Modules linked in: nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG
> sctp libcrc32c e1000e tipc udp_tunnel ip6_udp_tunnel 8021q garp iTCO_wdt
> xt_physdev br_netfilter bridge stp llc nf_conntrack_ipv4 nf_defrag_ipv4
> ipmiq_drv(O) sio_mmc(O) ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6
> nf_defrag_ipv6 xt_state nf_conntrack lockd ip6table_filter event_drv(O)
> ip6_tables grace pt_timer_info(O) ddi(O) usb_storage ixgbe igb i2c_i801
> iTCO_vendor_support i2c_algo_bit ioatdma intel_ips i2c_core pcspkr sunrpc ptp
> mdio dca pps_core lpc_ich tpm_tis mfd_core tpm [last unloaded: iTCO_wdt]
> [375832.573693] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G O 4.4.0
> #14
> [375832.581385] Hardware name: PT AMC124/Base Board Product Name, BIOS
> LGNAJFIP.PTI.0012.P15 01/15/2014
> [375832.591028] task: ffff880351a89b40 ti: ffff880351a90000 task.ti:
> ffff880351a90000
> [375832.599026] RIP: 0010:[<ffffffff810c3566>] [<ffffffff810c3566>]
> queued_spin_lock_slowpath+0xe6/0x160
> [375832.608964] RSP: 0018:ffff88035fc83d58 EFLAGS: 00010002
> [375832.614825] RAX: 0000000000001447 RBX: 0000000000000292 RCX:
> ffff88035fc95fc0
> [375832.622743] RDX: 000001a400015ff4 RSI: 0000000000140000 RDI:
> ffff880351232f80
> [375832.630567] RBP: ffff88035fc83d58 R08: 0000000000000101 R09:
> 0000000000000004
> [375832.638348] R10: 0000000000000000 R11: 0000000000000000 R12:
> 0000000001001002
> [375832.645919] R13: 0000000000000001 R14: 0000000000000000 R15:
> 0000000000000000
> [375832.653610] FS: 0000000000000000(0000) GS:ffff88035fc80000(0000)
> knlGS:0000000000000000
> [375832.662317] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [375832.668483] CR2: 000001a400015ff4 CR3: 0000000001c0a000 CR4:
> 00000000000006e0
> [375832.676133] Stack:
> [375832.678344] ffff88035fc83d78 ffffffff816de2c1 ffff88034a8bba60
> ffff880351232f80
> [375832.686163] ffff88035fc83db8 ffffffff810bc592 ffff88035fc83dc8
> ffff880351758000
> [375832.694139] 0000000001001002 0000000000000000 00000000b802f4bd
> ffffffffa024e6f0
> [375832.702154] Call Trace:
> [375832.704844] <IRQ>
> [375832.707018] [<ffffffff816de2c1>] _raw_spin_lock_irqsave+0x31/0x40
> [375832.713970] [<ffffffff810bc592>] __wake_up+0x32/0x70
> [375832.719444] [<ffffffffa024e6f0>] ? tipc_recv_stream+0x370/0x370 [tipc]
> [375832.726589] [<ffffffff815bf890>] sock_def_wakeup+0x30/0x40
> [375832.732566] [<ffffffffa024e838>] tipc_sk_timeout+0x148/0x180 [tipc]
> [375832.739388] [<ffffffffa024e6f0>] ? tipc_recv_stream+0x370/0x370 [tipc]
> [375832.746507] [<ffffffff810e1644>] call_timer_fn+0x44/0x110
> [375832.752378] [<ffffffff810e0e6a>] ? cascade+0x4a/0x80
> [375832.757848] [<ffffffffa024e6f0>] ? tipc_recv_stream+0x370/0x370 [tipc]
> [375832.764871] [<ffffffff810e2c4c>] run_timer_softirq+0x22c/0x280
> [375832.771175] [<ffffffff81083d88>] __do_softirq+0xc8/0x260
> [375832.776958] [<ffffffff81084123>] irq_exit+0x83/0xb0
> [375832.782369] [<ffffffff816e0c65>] do_IRQ+0x65/0xf0
> [375832.787607] [<ffffffff816df13f>] common_interrupt+0x7f/0x7f
> [375832.793709] <EOI>
> [375832.795803] [<ffffffff81591bdd>] ? cpuidle_enter_state+0xad/0x200
> [375832.802765] [<ffffffff81591bc1>] ? cpuidle_enter_state+0x91/0x200
> [375832.809338] [<ffffffff81591d67>] cpuidle_enter+0x17/0x20
> [375832.815155] [<ffffffff810bcdc7>] call_cpuidle+0x37/0x60
> [375832.821184] [<ffffffff81591d43>] ? cpuidle_select+0x13/0x20
> [375832.827249] [<ffffffff810bd001>] cpu_startup_entry+0x211/0x2d0
> [375832.833535] [<ffffffff8103b213>] start_secondary+0x103/0x130
> [375832.839759] Code: 87 47 02 c1 e0 10 85 c0 74 38 48 89 c2 c1 e8 12 48 c1 ea
> 0c 83 e8 01 83 e2 30 48 98 48 81 c2 c0 5f 01 00 48 03 14 c5 00 b2 d1 81 <48> 89
> 0a 8b 41 08 85 c0 75 0d f3 90 8b 41 08 85 c0 74 f7 eb 02
> [375832.861151] RIP [<ffffffff810c3566>] queued_spin_lock_slowpath+0xe6/0x160
> [375832.868607] RSP <ffff88035fc83d58>
> [375832.872371] CR2: 000001a400015ff4
> [375832.876408] ---[ end trace f12e0074b180a165 ]---
> [375832.881433] Kernel panic - not syncing: Fatal exception in interrupt
> [375832.888391] Kernel Offset: disabled
> [375832.891968] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
^ permalink raw reply
* Re: [iproute2 1/1] man: tc-ife.8: man page for ife action
From: Stephen Hemminger @ 2016-05-02 22:10 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, phil, lucasb
In-Reply-To: <1462013884-4971-1-git-send-email-jhs@emojatatu.com>
On Sat, 30 Apr 2016 06:58:04 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> From: Lucas Bates <lucasb@mojatatu.com>
>
> Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Still waiting for a you to respond to my earlier suggestions about tc-ife.
Last version I saw was expecting header in include/linux which is not in
kernel source.
~/kernel/net-next$ ls include/uapi/linux/tc_ife.h
ls: cannot access include/uapi/linux/tc_ife.h: No such file or directory
You need to get that header in right place, and get it exported correctly.
^ permalink raw reply
* Re: [PATCH iproute2] tc: add bash-completion function
From: Stephen Hemminger @ 2016-05-02 22:14 UTC (permalink / raw)
To: Quentin Monnet; +Cc: alexei.starovoitov, hadi, netdev, vincent.jardin
In-Reply-To: <1461918431-6518-1-git-send-email-quentin.monnet@6wind.com>
On Fri, 29 Apr 2016 10:27:11 +0200
Quentin Monnet <quentin.monnet@6wind.com> wrote:
> Add function for command completion for tc in bash, and update Makefile
> to install it:
>
> - Under /usr/share/bash-completion/completions/ (default).
> - Or under /etc/bash_completions.d/, which is the old directory for
> bash-completion, if /usr/share/bash-completion/completions/ is not
> found AND /etc/bash_completions.d/ exists already.
>
> Inside iproute2 repository, the completion code is in a new
> `bash-completion` toplevel directory.
>
> Signed-off-by: Quentin Monnet <quentin.monnet@6wind.com>
Rather than having an if statement in the install; lets follow how
other paths are handles.
* default value should be what current distros use /usr/share
* other distro's can override it with environment variable.
Something like:
Makefile:
PREFIX?=/usr
LIBDIR?=$(PREFIX)/lib
SBINDIR?=/sbin
CONFDIR?=/etc/iproute2
DATADIR?=$(PREFIX)/share
DOCDIR?=$(DATADIR)/doc/iproute2
MANDIR?=$(DATADIR)/man
ARPDDIR?=/var/lib/arpd
KERNEL_INCLUDE?=/usr/include
BASH_COMPDIR?=$(DATADIR)/bash-completion/completions/
^ permalink raw reply
* Re: [PATCH] ip: add udp_csum, udp6_csum_tx, udp6_csum_rx control flags to ip l2tp add tunnel
From: Stephen Hemminger @ 2016-05-02 22:19 UTC (permalink / raw)
To: James Chapman; +Cc: Wang Shanker, netdev
In-Reply-To: <CAEwTi7SyKKh4de6TKYiuypWfOhzOCeD6k2uTLUfCmzQmvsNHWw@mail.gmail.com>
On Thu, 28 Apr 2016 15:50:47 +0100
James Chapman <jchapman@katalix.com> wrote:
> Yes, that looks like the problem.
>
> The comments in l2tp.h which indicate that the csum attributes are u8
> values are wrong. Code in net/l2tp/l2tp_netlink.c accesses these
> attributes using nla_get_flag().
>
> Please submit a patch to fix l2tp_tunnel_sock_create(). Include good
> change notes and your signed-off-by tag so that it gets reviewed. See
> Documentation/SubmittingPatches if you haven't submitted a kernel
> patch here before.
Thank you for fixing this. James is is correct.
Please format the patch according to the submission guidelines.
For example, checkpatch complains about current patch.
ERROR: code indent should use tabs where possible
#156: FILE: net/l2tp/l2tp_core.c:1379:
+ ! cfg->udp6_zero_tx_checksums;$
WARNING: please, no spaces at the start of a line
#156: FILE: net/l2tp/l2tp_core.c:1379:
+ ! cfg->udp6_zero_tx_checksums;$
ERROR: space prohibited after that '!' (ctx:ExW)
#156: FILE: net/l2tp/l2tp_core.c:1379:
+ ! cfg->udp6_zero_tx_checksums;
^
ERROR: code indent should use tabs where possible
#159: FILE: net/l2tp/l2tp_core.c:1381:
+ ! cfg->udp6_zero_rx_checksums;$
WARNING: please, no spaces at the start of a line
#159: FILE: net/l2tp/l2tp_core.c:1381:
+ ! cfg->udp6_zero_rx_checksums;$
ERROR: space prohibited after that '!' (ctx:ExW)
#159: FILE: net/l2tp/l2tp_core.c:1381:
+ ! cfg->udp6_zero_rx_checksums;
^
ERROR: Missing Signed-off-by: line(s)
I am sorry that maintainers may seem like picky teachers in school
always putting redline around spelling errors, but this is how we work to teach
others how to follow the process.
^ permalink raw reply
* Performance suggestions for bridging module?
From: Ben Greear @ 2016-05-02 22:50 UTC (permalink / raw)
To: netdev
Hello!
I have a network emulator module that acts a lot like an ethernet bridge.
It is implemented roughly like this:
Hook into the rx logic and steal packets in the rx-all logic, similar to how sniffers
work.
Then, it puts the packet onto a queue for transmit.
A kernel thread services this queue transmitting frames on a different NIC.
I am using spin-locks to protect this queue.
I am disabling LRO/GRO etc on the ixgbe NICs so that I don't have
to deal with linearization when trying to do corruptions and such. Re-enabling
LRO/GRO makes the transmit logic use less CPU, but the RX logic is the bottleneck
anyway it seems.
The code, which is GPL, is here, in case someone wants to take a look:
http://www.candelatech.com/downloads/wanlink/
What I see is that this is very sensitive to which CPU core does what.
If I run the transmitter thread on cpu-0, performance is awful. If I run
it on 1, then it is good. Sometimes, though hard to reproduce, I can run
right at 10Gbps bi-directional throughput. More often, it is stuck at
around 7Gbps bi-directional throughput.
I tried adding some prefetch logic, and that helped when emulating very long
latency (like, 10 seconds worth), but not sure I am really doing that optimally
either.
My basic question is: Any suggestion for an optimal CPU core configuration
(most likely including binding a NIC's irqs to a particular core)??
Any other suggestions for things to look for?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net 2/3] udp_offload: Set encapsulation before inner completes.
From: Alexander Duyck @ 2016-05-02 22:54 UTC (permalink / raw)
To: Jarno Rajahalme; +Cc: Netdev, Jesse Gross
In-Reply-To: <DB78A60B-3899-4767-AD0B-DCDCC65C04E1@ovn.org>
On Mon, May 2, 2016 at 2:21 PM, Jarno Rajahalme <jarno@ovn.org> wrote:
>
>> On Apr 29, 2016, at 8:46 PM, Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>
>> On Fri, Apr 29, 2016 at 3:28 PM, Jarno Rajahalme <jarno@ovn.org> wrote:
>>> UDP tunnel segmentation code relies on the inner offsets being set for
>>> an UDP tunnel GSO packet. The inner *_complete() functions will set
>>> the inner offsets only if the encapsulation is set before calling
>>> them, but udp_gro_complete() set it only after the inner *_complete()
>>> functions were done.
>>>
>>> Also, remove the setting of the inner_mac_header in udp_gro_complete()
>>> as it was wrongly set to the beginning of the UDP tunnel header rather
>>> than the inner MAC header.
>>>
>>> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
>>> ---
>>> net/ipv4/udp_offload.c | 8 +++++---
>>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>> index 0ed2daf..e330c0e 100644
>>> --- a/net/ipv4/udp_offload.c
>>> +++ b/net/ipv4/udp_offload.c
>>> @@ -399,6 +399,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>>>
>>> uh->len = newlen;
>>>
>>> + /* Set encapsulation before calling into inner gro_complete() functions
>>> + * to make them set up the inner offsets.
>>> + */
>>> + skb->encapsulation = 1;
>>> +
>>> rcu_read_lock();
>>>
>>> uo_priv = rcu_dereference(udp_offload_base);
>>> @@ -421,9 +426,6 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
>>> if (skb->remcsum_offload)
>>> skb_shinfo(skb)->gso_type |= SKB_GSO_TUNNEL_REMCSUM;
>>>
>>> - skb->encapsulation = 1;
>>> - skb_set_inner_mac_header(skb, nhoff + sizeof(struct udphdr));
>>> -
>>> return err;
>>> }
>>>
>>> --
>>> 2.7.4
>>>
>>
>> So looking over this I think this patch is just a band-aid and it
>> isn't really fixing much of anything. For example I cannot see where
>
> It fixes the immediate bug/problem that segmentation of GRO UDP tunnel packet fails due to incorrectly set inner MAC offset and/or missing inner network offset.
The problem is I think this will introduce other issues as there are
now situations where the inner MAC offset never gets set. For example
did you try testing with GUE carrying either an IPIP or SIT tunnel?
>From what I can tell it looks like you are trying to fix VXLAN and
similar offloads, and Tom is focused on GUE. What you will probably
need to do is add some code to ipip_gro_complete and sit_gro_complete
so that if skb->encapsulation is set before you call the function it
will set the inner MAC offset to the same offset as the inner network
header. Otherwise you run the risk of screwing up segmentation
because the UDP tunnel segment code will use the inner mac header
offset when computing the tunnel header length and get it completely
wrong.
>> the inner transport offset is ever set. From what I can tell it never
>> is.
>>
>
> inner transport offset is set in validate_xmit_skb(), but you are right, it is not set by the GRO complete code path. AFAIK no-one uses it before reaching validate_xmit_skb(), though. The documentation in (net-next) Documentation/networking/segmentation-offloads.txt could be fixed by removing the inner transport header from UDP/GRE tunnel case, as it is not used by either the GRE or UDP tunnel code.
Actually that is an interesting point. Right now we need to keep the
inner transport header around because that is getting set. If we were
to enforce the use of csum_start as the inner transport header offset,
then we could assume that transport_header is always the outer-most
transport header. We might be able to drop a bit of space from the
skbuff by getting rid of it. If nothing else it means one less header
offset we would have to copy.
- Alex
^ 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