* [PATCH] Fix handling of verdicts after NF_QUEUE
From: Debabrata Banerjee @ 2017-12-13 20:33 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Greg Kroah-Hartman, David S . Miller, netfilter-devel, coreteam,
netdev, stable, dbanerje
A verdict of NF_STOLEN after NF_QUEUE will cause an incorrect return value
and a potential kernel panic via double free of skb's
This was broken by commit 7034b566a4e7 ("netfilter: fix nf_queue handling")
and subsequently fixed in v4.10 by commit c63cbc460419 ("netfilter:
use switch() to handle verdict cases from nf_hook_slow()"). However that
commit cannot be cleanly cherry-picked to v4.9
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
This fix is only needed for v4.9 stable since v4.10+ does not have the
issue
---
net/netfilter/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 004af030ef1a..d869ea50623e 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -364,6 +364,11 @@ int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state)
ret = nf_queue(skb, state, &entry, verdict);
if (ret == 1 && entry)
goto next_hook;
+ } else {
+ /* Implicit handling for NF_STOLEN, as well as any other
+ * non conventional verdicts.
+ */
+ ret = 0;
}
return ret;
}
--
2.15.1
^ permalink raw reply related
* [PATCH iproute2] ip: add vxcan to help text
From: Oliver Hartkopp @ 2017-12-13 20:21 UTC (permalink / raw)
To: linux-can, netdev, Stephen Hemminger; +Cc: Oliver Hartkopp
Add missing tag 'vxcan' inside the help text which was missing in commit
efe459c76d35f ('ip: link add vxcan support').
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
ip/ipaddress.c | 2 +-
ip/iplink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 8057011e..f150d919 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -74,7 +74,7 @@ static void usage(void)
fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr | noprefixroute | autojoin ]\n");
fprintf(stderr, "LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]\n");
fprintf(stderr, "LFT := forever | SECONDS\n");
- fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n");
+ fprintf(stderr, "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n");
fprintf(stderr, " bridge | bond | ipoib | ip6tnl | ipip | sit | vxlan | lowpan |\n");
fprintf(stderr, " gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan | vti |\n");
fprintf(stderr, " nlmon | can | bond_slave | ipvlan | geneve | bridge_slave |\n");
diff --git a/ip/iplink.c b/ip/iplink.c
index 0a8eb56f..e83f1477 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -109,7 +109,7 @@ void iplink_usage(void)
"\n"
" ip link help [ TYPE ]\n"
"\n"
- "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n"
+ "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n"
" bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |\n"
" gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |\n"
" vti | nlmon | team_slave | bond_slave | ipvlan | geneve |\n"
--
2.15.1
^ permalink raw reply related
* Re: [PATCH iproute2] Show 'external' link mode in output
From: Stephen Hemminger @ 2017-12-13 20:15 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: netdev, phild
In-Reply-To: <20171212202319.GA7066@ipom.com>
On Tue, 12 Dec 2017 12:23:19 -0800
Phil Dibowitz <phil@ipom.com> wrote:
> Recently `external` support was added to the tunnel drivers, but there is no way
> to introspect this from userspace. This adds support for that.
>
> Now `ip -details link` shows it:
>
> ```
> 7: tunl60@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group
> default qlen 1
> link/tunnel6 :: brd :: promiscuity 0
> ip6tnl external any remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> ```
>
> Signed-off-by: Phil Dibowitz <phil@ipom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: avoid skb_warn_bad_offload on IS_ERR
From: David Miller @ 2017-12-13 20:14 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, edumazet, willemb
In-Reply-To: <20171212163904.209480-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload warns when packets enter the GSO stack that
> require skb_checksum_help or vice versa. Do not warn on arbitrary
> bad packets. Packet sockets can craft many. Syzkaller was able to
> demonstrate another one with eth_type games.
>
> In particular, suppress the warning when segmentation returns an
> error, which is for reasons other than checksum offload.
>
> See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
> called on skb requiring segmentation") for context on this warning.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks Willem.
^ permalink raw reply
* Re: [PATCH net-next] net: sk_pacing_shift_update() helper
From: David Miller @ 2017-12-13 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: nbd, netdev, johannes.berg, toke, kir
In-Reply-To: <1513089259.25033.51.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Dec 2017 06:34:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 3a9b76fd0db9 ("tcp: allow drivers to tweak TSQ logic")
> I gave a code sample to set sk->sk_pacing_shift that was not complete.
>
> Better add a helper that can be used by drivers without worries,
> and maybe amended in the future.
>
> A wifi driver might use it from its ndo_start_xmit()
>
> Following call would setup TCP to allow up to ~8ms of queued data per
> flow.
>
> sk_pacing_shift_update(skb->sk, 7);
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/3] net: phy: add support to detect 100BASE-T1 capability
From: Andrew Lunn @ 2017-12-13 20:11 UTC (permalink / raw)
To: Lucas Stach; +Cc: Florian Fainelli, netdev, kernel, patchwork-lst
In-Reply-To: <20171213173751.12722-1-l.stach@pengutronix.de>
On Wed, Dec 13, 2017 at 06:37:49PM +0100, Lucas Stach wrote:
> 100BASE-T1 is the automotive ethernet standard 802.3bw-2015. Currently
> we don't detect any valid modes for PHYs, which only support this
> standard. Add support to detect the common 100Mbit full-duplex mode.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/net/phy/phy_device.c | 2 ++
> include/uapi/linux/mii.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 67f25ac29025..8ef48b38d97b 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1607,6 +1607,8 @@ int genphy_config_init(struct phy_device *phydev)
> if (val < 0)
> return val;
>
> + if (val & ESTATUS_100T1_FULL)
> + features |= SUPPORTED_100baseT_Full;
Hi Lucas
Why did you decide to do this, and not add a SUPPORTED_100baseT1?
Could a device support both 100-BASE-T and 100-BASE-T1? If at some
point we need to differentiate between them, it is going to be
hard. Especially since this is part of the kernel ABI.
Andrew
^ permalink raw reply
* Re: [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Eric Dumazet @ 2017-12-13 20:10 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: richardcochran, davem, Willem de Bruijn
In-Reply-To: <20171213194106.128322-1-willemdebruijn.kernel@gmail.com>
On Wed, 2017-12-13 at 14:41 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> skb_complete_tx_timestamp must ingest the skb it is passed. Call
> kfree_skb if the skb cannot be enqueued.
>
> Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
> Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
> Reported-by: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: use rhashtable for fdbs
From: David Miller @ 2017-12-13 20:10 UTC (permalink / raw)
To: nikolay; +Cc: netdev, bridge, roopa, stephen, srn
In-Reply-To: <1513087370-4791-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 12 Dec 2017 16:02:50 +0200
> Before this patch the bridge used a fixed 256 element hash table which
> was fine for small use cases (in my tests it starts to degrade
> above 1000 entries), but it wasn't enough for medium or large
> scale deployments. Modern setups have thousands of participants in a
> single bridge, even only enabling vlans and adding a few thousand vlan
> entries will cause a few thousand fdbs to be automatically inserted per
> participating port. So we need to scale the fdb table considerably to
> cope with modern workloads, and this patch converts it to use a
> rhashtable for its operations thus improving the bridge scalability.
> Tests show the following results (10 runs each), at up to 1000 entries
> rhashtable is ~3% slower, at 2000 rhashtable is 30% faster, at 3000 it
> is 2 times faster and at 30000 it is 50 times faster.
> Obviously this happens because of the properties of the two constructs
> and is expected, rhashtable keeps pretty much a constant time even with
> 10000000 entries (tested), while the fixed hash table struggles
> considerably even above 10000.
> As a side effect this also reduces the net_bridge struct size from 3248
> bytes to 1344 bytes. Also note that the key struct is 8 bytes.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> After this I'll post patches for the per-port fdb limit option. Later we
> can get rid of hash_lock altogether though that requires much more
> careful changes.
Nice work Nikolay, applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next v2] ip6_vti: adjust vti mtu according to mtu of output device
From: David Miller @ 2017-12-13 20:09 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, steffen.klassert, pvorel, shannon.nelson
In-Reply-To: <1513086812-24896-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Tue, 12 Dec 2017 16:53:32 +0300
> + if (tdev) {
> + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
> + IPV6_MIN_MTU);
> + }
Please don't use curly braces for a single-statement basic block.
Thank you.
^ permalink raw reply
* Re: [RFC PATCH] reuseport: compute the ehash only if needed
From: David Miller @ 2017-12-13 20:08 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kraig, edumazet
In-Reply-To: <af8a2d2c27b6f91ca7a7c65ac375ce2ba7aa4764.1513084090.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 12 Dec 2017 14:09:28 +0100
> When a reuseport socket group is using a BPF filter to distribute
> the packets among the sockets, we don't need to compute any hash
> value, but the current reuseport_select_sock() requires the
> caller to compute such hash in advance.
>
> This patch reworks reuseport_select_sock() to compute the hash value
> only if needed - missing or failing BPF filter. Since different
> hash functions have different argument types - ipv4 addresses vs ipv6
> ones - to avoid over-complicate the interface, reuseport_select_sock()
> is now a macro.
>
> Additionally, the sk_reuseport test is move inside reuseport_select_sock,
> to avoid some code duplication.
>
> Overall this gives small but measurable performance improvement
> under UDP flood while using SO_REUSEPORT + BPF.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I don't doubt that this improves the case where the hash is elided, but
I suspect it makes things slower othewise.
You're doing two function calls for an operation that used to require
just one in the bottom of the call chain.
You're also putting something onto the stack that the compiler can't
possibly optimize into purely using cpu registers to hold.
^ permalink raw reply
* Re: [PATCH][next] net: phy: meson-gxl: make function meson_gxl_read_status static
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: colin.king
Cc: andrew, f.fainelli, carlo, khilman, netdev, linux-arm-kernel,
linux-amlogic, kernel-janitors, linux-kernel
In-Reply-To: <20171212130311.17185-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 12 Dec 2017 13:03:11 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The function meson_gxl_read_status is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'meson_gxl_read_status' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell10g: remove XGMII as an option for 88x3310
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOk3i-00010j-0V@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 12:53:18 +0000
> Remove XGMII as an option for the 88x3310 PHY driver, as the PHY doesn't
> support XGMII's 32-bit data lanes. It supports USXGMII, which is not
> XGMII, but a single-lane serdes interface - see
> https://developer.cisco.com/site/usgmii-usxgmii/
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] of_mdio / mdiobus: ensure mdio devices have fwnode correctly populated
From: David Miller @ 2017-12-13 20:02 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1eOi7f-0002Rs-K7-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 10:49:15 +0000
> Ensure that all mdio devices populate the struct device fwnode pointer
> as well as the of_node pointer to allow drivers that wish to use
> fwnode APIs to work.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: phy: fix resume handling
From: David Miller @ 2017-12-13 20:00 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOi48-0002N2-QC@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 10:45:36 +0000
> When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes
> to other registers, or reset the registers to power-on defaults.
> Micrel PHYs do this for their interrupt registers.
>
> The current structure of phylib tries to enable interrupts before
> resuming (and releasing) the BMCR_PDOWN bit. This fails, causing
> Micrel PHYs to stop working after a suspend/resume sequence if they
> are using interrupts.
>
> Fix this by ensuring that the PHY driver resume methods do not take
> the phydev->lock mutex themselves, but the callers of phy_resume()
> take that lock. This then allows us to move the call to phy_resume()
> before we enable interrupts in phy_start().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: vf610-zii-dev: use XAUI for DSA link ports
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel
Cc: andrew, f.fainelli, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt, kernel, shawnguo, stefan, vivien.didelot
In-Reply-To: <E1eOgsp-0001Ab-9x@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 09:29:51 +0000
> Use XAUI rather than XGMII for DSA link ports, as this is the interface
> mode that the switches actually use. XAUI is the 4 lane bus with clock
> per direction, whereas XGMII is a 32 bit bus with clock.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> This must be applied along with patch 1 to avoid breakage.
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: allow XAUI phy interface mode
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stefan-XLVq0VzYD2Y,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <E1eOgsk-0001AU-5z-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 09:29:46 +0000
> XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
> four serial lanes per direction. The 88e6190 supports XAUI but not
> XGMII as it doesn't have enough pins. The same is true of 88e6176.
>
> Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
> accepting XGMII for backwards compatibility.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: x86 boot broken on -rc1?
From: Jakub Kicinski @ 2017-12-13 19:58 UTC (permalink / raw)
To: Björn Töpel; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <CAJ+HfNicp5rKpUmx9_Y8FZDd73Ob9uquG0P7sY1nGDCY8p0NNw@mail.gmail.com>
On Wed, 13 Dec 2017 20:37:02 +0100, Björn Töpel wrote:
> 2017-12-02 1:39 GMT+01:00 Jakub Kicinski:
> > [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>
> Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
>
> Did you bisect it? I haven't got around yet.
Yup, it's fixed but I'm not sure who far it trickled down the various
trees:
947134d9b00f ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages calculation")
^ permalink raw reply
* [patch iproute2] tc: fix json array closing
From: Jiri Pirko @ 2017-12-13 19:56 UTC (permalink / raw)
To: netdev; +Cc: stephen
From: Jiri Pirko <jiri@mellanox.com>
Fixes: 2704bd625583 ("tc: jsonify actions core")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
tc/m_action.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index 13f942b..8185819 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -378,7 +378,7 @@ tc_print_action(FILE *f, const struct rtattr *arg, unsigned short tot_acts)
}
}
- close_json_object();
+ close_json_array(PRINT_JSON, NULL);
return 0;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
From: David Miller @ 2017-12-13 19:53 UTC (permalink / raw)
To: baijiaju1990; +Cc: jes, jes, netdev, linux-kernel
In-Reply-To: <1513068592-23632-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Tue, 12 Dec 2017 16:49:52 +0800
> The driver may sleep under a spinlock.
> The function call path is:
> rr_close (acquire the spinlock)
> free_irq --> may sleep
>
> To fix it, free_irq is moved to the place without holding the spinlock.
>
> This bug is found by my static analysis tool(DSAC) and checked by my code review.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/3] r8169: extend PCI core and switch to device-managed functions in probe
From: David Miller @ 2017-12-13 19:52 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, bhelgaas, netdev, linux-pci
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 12 Dec 2017 07:34:26 +0100
> Probe error path and remove callback can be significantly simplified
> by using device-managed functions. To be able to do this in the r8169
> driver we need a device-managed version of pci_set_mwi first.
>
> v2:
> Change patch 1 based on Björn's review comments and add his Acked-by.
Series applied, thanks.
^ permalink raw reply
* Re: thunderx sgmii interface hang
From: Andrew Lunn @ 2017-12-13 19:43 UTC (permalink / raw)
To: Tim Harvey; +Cc: netdev, Sunil Goutham
In-Reply-To: <CAJ+vNU3UwuTrDqoDZNavEqSG_gs3=bpWRzmsp-ao3fsYvMoY2g@mail.gmail.com>
> The nic appears to work fine (pings, TCP etc) up until a performance
> test is attempted.
> When an iperf bandwidth test is attempted the nic ends up in a state
> where truncated-ip packets are being sent out (per a tcpdump from
> another board):
Hi Tim
Are pause frames supported? Have you tried turning them off?
Can you reproduce the issue with UDP? Or is it TCP only?
Andrew
^ permalink raw reply
* [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Willem de Bruijn @ 2017-12-13 19:41 UTC (permalink / raw)
To: netdev; +Cc: richardcochran, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
skb_complete_tx_timestamp must ingest the skb it is passed. Call
kfree_skb if the skb cannot be enqueued.
Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
Reported-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/skbuff.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6b0ff396fa9d..a592ca025fc4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4293,7 +4293,7 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
struct sock *sk = skb->sk;
if (!skb_may_tx_timestamp(sk, false))
- return;
+ goto err;
/* Take a reference to prevent skb_orphan() from freeing the socket,
* but only if the socket refcount is not zero.
@@ -4302,7 +4302,11 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
*skb_hwtstamps(skb) = *hwtstamps;
__skb_complete_tx_timestamp(skb, sk, SCM_TSTAMP_SND, false);
sock_put(sk);
+ return;
}
+
+err:
+ kfree_skb(skb);
}
EXPORT_SYMBOL_GPL(skb_complete_tx_timestamp);
--
2.15.1.504.g5279b80103-goog
^ permalink raw reply related
* Re: x86 boot broken on -rc1?
From: Björn Töpel @ 2017-12-13 19:37 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <20171201163954.2e356787@cakuba.netronome.com>
2017-12-02 1:39 GMT+01:00 Jakub Kicinski <jakub.kicinski@netronome.com>:
> Hi!
>
> I'm hitting these after DaveM pulled rc1 into net-next on my Xeon
> E5-2630 v4 box. It also happens on linux-next. Did anyone else
> experience it? (.config attached)
>
> [ 5.003771] WARNING: CPU: 14 PID: 1 at ../arch/x86/events/intel/uncore.c:936 uncore_pci_probe+0x285/0x2b0
> [ 5.007544] Modules linked in:
> [ 5.007544] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.007544] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.007544] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.007544] RIP: 0010:uncore_pci_probe+0x285/0x2b0
> [ 5.007544] RSP: 0000:ffffad8580163d10 EFLAGS: 00010286
> [ 5.007544] RAX: ffff98576cc3df30 RBX: ffffffffb08037e0 RCX: ffffffffb0c1a120
> [ 5.007544] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb0c1a960
> [ 5.007544] RBP: ffff985b6c00ac00 R08: fffffffffffffffe R09: 00000000000fffff
> [ 5.007544] R10: ffff98576f1b6018 R11: 0000000000000022 R12: ffff985b6c641000
> [ 5.007544] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000001
> [ 5.007544] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.007544] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.007544] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.007544] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.007544] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.007544] Call Trace:
> [ 5.007544] local_pci_probe+0x3d/0x90
> [ 5.007544] ? pci_match_device+0xd9/0x100
> [ 5.007544] pci_device_probe+0x122/0x180
> [ 5.007544] driver_probe_device+0x246/0x330
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] __driver_attach+0x8a/0x90
> [ 5.007544] ? driver_probe_device+0x330/0x330
> [ 5.007544] bus_for_each_dev+0x5c/0x90
> [ 5.007544] bus_add_driver+0x196/0x220
> [ 5.007544] driver_register+0x57/0xc0
> [ 5.007544] intel_uncore_init+0x1e3/0x249
> [ 5.007544] ? uncore_type_init+0x193/0x193
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] do_one_initcall+0x4b/0x190
> [ 5.007544] kernel_init_freeable+0x16e/0x1f5
> [ 5.007544] ? rest_init+0xd0/0xd0
> [ 5.007544] kernel_init+0xa/0x100
> [ 5.007544] ret_from_fork+0x1f/0x30
> [ 5.007544] Code: 48 8b 52 08 48 85 d2 74 0d 89 44 24 04 48 89 df ff d2 8b 44 24 04 48 89 df 89 44 24 04 e8 54 0a 1c 00 8b 44 24 0
> [ 5.007544] ---[ end trace 4dc4c3d5f5afcd2f ]---
> [ 5.244504] bdx_uncore: probe of 0000:ff:08.2 failed with error -22
> [ 5.251604] bdx_uncore: probe of 0000:ff:0b.1 failed with error -22
> [ 5.258711] bdx_uncore: probe of 0000:ff:10.1 failed with error -22
> [ 5.265819] bdx_uncore: probe of 0000:ff:14.0 failed with error -22
> [ 5.272919] bdx_uncore: probe of 0000:ff:14.1 failed with error -22
> [ 5.280019] bdx_uncore: probe of 0000:ff:15.0 failed with error -22
> [ 5.287112] bdx_uncore: probe of 0000:ff:15.1 failed with error -22
> [ 5.294376] WARNING: CPU: 1 PID: 15 at ../arch/x86/events/intel/uncore.c:1065 uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] Modules linked in:
> [ 5.298362] CPU: 1 PID: 15 Comm: cpuhp/1 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.298362] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.298362] task: 00000000ae78bc8f task.stack: 00000000f79660c1
> [ 5.298362] RIP: 0010:uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] RSP: 0000:ffffad85833b3db8 EFLAGS: 00010213
> [ 5.298362] RAX: 0000000000000000 RBX: ffff9857669b0200 RCX: 0000000000000001
> [ 5.298362] RDX: ffff985b6f000000 RSI: ffff985b66580400 RDI: ffffffffb0c1ae8c
> [ 5.298362] RBP: ffff985b66580400 R08: ffffffffb0c1ae8c R09: 0000000000000001
> [ 5.298362] R10: 0000000000000000 R11: 00000000003d0900 R12: 0000000000000000
> [ 5.298362] R13: ffffffffffffffff R14: 0000000000000001 R15: 0000000000000008
> [ 5.298362] FS: 0000000000000000(0000) GS:ffff985b6f000000(0000) knlGS:0000000000000000
> [ 5.298362] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.298362] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.298362] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.298362] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.298362] Call Trace:
> [ 5.298362] uncore_event_cpu_online+0x283/0x340
> [ 5.298362] ? uncore_event_cpu_offline+0x180/0x180
> [ 5.298362] cpuhp_invoke_callback+0x8c/0x620
> [ 5.298362] ? __schedule+0x1ad/0x6c0
> [ 5.298362] ? sort_range+0x20/0x20
> [ 5.298362] cpuhp_thread_fun+0xbc/0x140
> [ 5.298362] smpboot_thread_fn+0x114/0x1d0
> [ 5.298362] kthread+0x111/0x130
> [ 5.298362] ? kthread_create_on_node+0x40/0x40
> [ 5.298362] ret_from_fork+0x1f/0x30
> [ 5.298362] Code: 2a 44 89 73 10 41 83 c4 01 48 81 c5 40 01 00 00 45 3b 20 7c cf 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f f
> [ 5.298362] ---[ end trace 4dc4c3d5f5afcd30 ]---
> [ 5.504808] Scanning for low memory corruption every 60 seconds
> [ 5.512347] Initialise system trusted keyrings
> [ 5.517470] workingset: timestamp_bits=40 max_order=23 bucket_order=0
> [ 5.524840] BUG: unable to handle kernel paging request at 0000000023314bf4
> [ 5.528761] IP: __kmalloc_track_caller+0xa8/0x210
> [ 5.528761] PGD 185c0a067 P4D 185c0a067 PUD 185c0c067 PMD 0
> [ 5.528761] Oops: 0000 [#1] PREEMPT SMP
> [ 5.528761] Modules linked in:
> [ 5.528761] CPU: 14 PID: 1 Comm: swapper/0 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.528761] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.528761] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.528761] RIP: 0010:__kmalloc_track_caller+0xa8/0x210
> [ 5.528761] RSP: 0000:ffffad8580163d58 EFLAGS: 00010286
> [ 5.528761] RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 000000000012ce0e
> [ 5.528761] RDX: 000000000012cd0e RSI: 000000000012cd0e RDI: 000000000001dde0
> [ 5.528761] RBP: ffff985700000001 R08: ffff98576f407c00 R09: ffffffffb071edbf
> [ 5.528761] R10: ffffd54de1995600 R11: ffff985b6655915f R12: 0000000000000004
> [ 5.528761] R13: 00000000014000c0 R14: ffffffffb026c239 R15: ffff98576f407c00
> [ 5.528761] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.528761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.528761] CR2: ffffffffffffffff CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.528761] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.528761] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.528761] Call Trace:
> [ 5.528761] kstrdup+0x2d/0x60
> [ 5.528761] __kernfs_new_node+0x29/0x130
> [ 5.528761] kernfs_new_node+0x24/0x50
> [ 5.528761] kernfs_create_link+0x29/0x90
> [ 5.528761] sysfs_do_create_link_sd.isra.0+0x5d/0xc0
> [ 5.528761] sysfs_slab_add+0x1f5/0x270
> [ 5.528761] ? set_debug_rodata+0x11/0x11
> [ 5.528761] slab_sysfs_init+0x8b/0xfa
> [ 5.528761] ? kmem_cache_init+0xf9/0xf9
> [ 5.528761] do_one_initcall+0x4b/0x190
> [ 5.528761] kernel_init_freeable+0x16e/0x1f5
> [ 5.528761] ? rest_init+0xd0/0xd0
> [ 5.528761] kernel_init+0xa/0x100
> [ 5.528761] ret_from_fork+0x1f/0x30
> [ 5.528761] Code: 49 63 47 20 49 8b 3f 48 8d 8a 00 01 00 00 48 8b 5c 05 00 48 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 ab 48 85 db 7
> [ 5.528761] RIP: __kmalloc_track_caller+0xa8/0x210 RSP: ffffad8580163d58
> [ 5.528761] CR2: ffffffffffffffff
> [ 5.528761] ---[ end trace 4dc4c3d5f5afcd31 ]---
> [ 5.773089] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 5.773089]
> [ 5.777076] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
Did you bisect it? I haven't got around yet.
Björn
^ permalink raw reply
* [PATCH iproute2 3/3] ip: gre: fix IFLA_GRE_LINK attribute sizing
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Attribute IFLA_GRE_LINK is 32 bit long, not 8 bit.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 6f82fb4..09f1e44 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -155,7 +155,7 @@ get_failed:
tos = rta_getattr_u8(greinfo[IFLA_GRE_TOS]);
if (greinfo[IFLA_GRE_LINK])
- link = rta_getattr_u8(greinfo[IFLA_GRE_LINK]);
+ link = rta_getattr_u32(greinfo[IFLA_GRE_LINK]);
if (greinfo[IFLA_GRE_ENCAP_TYPE])
encaptype = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_TYPE]);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 2/3] ip/tunnel: Use get_addr() instead of get_prefix() for local/remote endpoints
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Manual page ip-link(8) states that both local and remote accept
IPADDR not PREFIX. Use get_addr() instead of get_prefix() to
parse local/remote endpoint address correctly.
Force corresponding address family instead of using preferred_family
to catch weired cases as shown below.
Before this patch it is possible to create tunnel with commands:
ip li add dev ip6gre2 type ip6gre local fe80::1/64 remote fe80::2/64
ip -4 li add dev ip6gre2 type ip6gre local 10.0.0.1/24 remote 10.0.0.2/24
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/ip6tunnel.c | 8 ++------
ip/link_gre6.c | 8 ++------
ip/link_ip6tnl.c | 12 ++++--------
ip/link_vti6.c | 8 ++++----
4 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
index 4563e1e..b8db49c 100644
--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -170,17 +170,13 @@ static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm2 *p)
inet_prefix raddr;
NEXT_ARG();
- get_prefix(&raddr, *argv, preferred_family);
- if (raddr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&raddr, *argv, AF_INET6);
memcpy(&p->raddr, &raddr.data, sizeof(p->raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix laddr;
NEXT_ARG();
- get_prefix(&laddr, *argv, preferred_family);
- if (laddr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&laddr, *argv, AF_INET6);
memcpy(&p->laddr, &laddr.data, sizeof(p->laddr));
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/link_gre6.c b/ip/link_gre6.c
index 0a82eae..c22fded 100644
--- a/ip/link_gre6.c
+++ b/ip/link_gre6.c
@@ -257,17 +257,13 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&raddr, &addr.data, sizeof(raddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&laddr, &addr.data, sizeof(laddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
diff --git a/ip/link_ip6tnl.c b/ip/link_ip6tnl.c
index 43287ab..4ab337f 100644
--- a/ip/link_ip6tnl.c
+++ b/ip/link_ip6tnl.c
@@ -184,18 +184,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
- memcpy(&raddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&raddr, addr.data, sizeof(raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
- memcpy(&laddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&laddr, addr.data, sizeof(laddr));
} else if (matches(*argv, "dev") == 0) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index f665520..84824a5 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -164,14 +164,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&daddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&daddr, addr.data, sizeof(daddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&saddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&saddr, addr.data, sizeof(saddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
--
1.7.10.4
^ permalink raw reply related
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