* [PATCH net] net/page_pool: Fix inconsistent lock state warning
From: Tariq Toukan @ 2018-07-17 15:10 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Eran Ben Elisha, Tariq Toukan, Jesper Dangaard Brouer
Fix the warning below by calling the ptr_ring_consume_bh,
which uses spin_[un]lock_bh.
[ 179.064300] ================================
[ 179.069073] WARNING: inconsistent lock state
[ 179.073846] 4.18.0-rc2+ #18 Not tainted
[ 179.078133] --------------------------------
[ 179.082907] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 179.089637] swapper/21/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 179.095478] 00000000963d1995 (&(&r->consumer_lock)->rlock){+.?.}, at:
__page_pool_empty_ring+0x61/0x100
[ 179.105988] {SOFTIRQ-ON-W} state was registered at:
[ 179.111443] _raw_spin_lock+0x35/0x50
[ 179.115634] __page_pool_empty_ring+0x61/0x100
[ 179.120699] page_pool_destroy+0x32/0x50
[ 179.125204] mlx5e_free_rq+0x38/0xc0 [mlx5_core]
[ 179.130471] mlx5e_close_channel+0x20/0x120 [mlx5_core]
[ 179.136418] mlx5e_close_channels+0x26/0x40 [mlx5_core]
[ 179.142364] mlx5e_close_locked+0x44/0x50 [mlx5_core]
[ 179.148509] mlx5e_close+0x42/0x60 [mlx5_core]
[ 179.153936] __dev_close_many+0xb1/0x120
[ 179.158749] dev_close_many+0xa2/0x170
[ 179.163364] rollback_registered_many+0x148/0x460
[ 179.169047] rollback_registered+0x56/0x90
[ 179.174043] unregister_netdevice_queue+0x7e/0x100
[ 179.179816] unregister_netdev+0x18/0x20
[ 179.184623] mlx5e_remove+0x2a/0x50 [mlx5_core]
[ 179.190107] mlx5_remove_device+0xe5/0x110 [mlx5_core]
[ 179.196274] mlx5_unregister_interface+0x39/0x90 [mlx5_core]
[ 179.203028] cleanup+0x5/0xbfc [mlx5_core]
[ 179.208031] __x64_sys_delete_module+0x16b/0x240
[ 179.213640] do_syscall_64+0x5a/0x210
[ 179.218151] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 179.224218] irq event stamp: 334398
[ 179.228438] hardirqs last enabled at (334398): [<ffffffffa511d8b7>]
rcu_process_callbacks+0x1c7/0x790
[ 179.239178] hardirqs last disabled at (334397): [<ffffffffa511d872>]
rcu_process_callbacks+0x182/0x790
[ 179.249931] softirqs last enabled at (334386): [<ffffffffa509732e>] irq_enter+0x5e/0x70
[ 179.259306] softirqs last disabled at (334387): [<ffffffffa509741c>] irq_exit+0xdc/0xf0
[ 179.268584]
[ 179.268584] other info that might help us debug this:
[ 179.276572] Possible unsafe locking scenario:
[ 179.276572]
[ 179.283877] CPU0
[ 179.286954] ----
[ 179.290033] lock(&(&r->consumer_lock)->rlock);
[ 179.295546] <Interrupt>
[ 179.298830] lock(&(&r->consumer_lock)->rlock);
[ 179.304550]
[ 179.304550] *** DEADLOCK ***
Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/page_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 68bf07206744..43a932cb609b 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -269,7 +269,7 @@ static void __page_pool_empty_ring(struct page_pool *pool)
struct page *page;
/* Empty recycle ring */
- while ((page = ptr_ring_consume(&pool->ring))) {
+ while ((page = ptr_ring_consume_bh(&pool->ring))) {
/* Verify the refcnt invariant of cached pages */
if (!(page_ref_count(page) == 1))
pr_crit("%s() page_pool refcnt %d violation\n",
--
1.8.3.1
^ permalink raw reply related
* [PATCH net] net/xdp: Fix suspicious RCU usage warning
From: Tariq Toukan @ 2018-07-17 15:10 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Eran Ben Elisha, Tariq Toukan, Jesper Dangaard Brouer
In-Reply-To: <1531840238-30818-1-git-send-email-tariqt@mellanox.com>
Fix the warning below by calling rhashtable_lookup under
RCU read lock.
[ 342.450870] WARNING: suspicious RCU usage
[ 342.455856] 4.18.0-rc2+ #17 Tainted: G O
[ 342.462210] -----------------------------
[ 342.467202] ./include/linux/rhashtable.h:481 suspicious rcu_dereference_check() usage!
[ 342.476568]
[ 342.476568] other info that might help us debug this:
[ 342.476568]
[ 342.486978]
[ 342.486978] rcu_scheduler_active = 2, debug_locks = 1
[ 342.495211] 4 locks held by modprobe/3934:
[ 342.500265] #0: 00000000e23116b2 (mlx5_intf_mutex){+.+.}, at:
mlx5_unregister_interface+0x18/0x90 [mlx5_core]
[ 342.511953] #1: 00000000ca16db96 (rtnl_mutex){+.+.}, at: unregister_netdev+0xe/0x20
[ 342.521109] #2: 00000000a46e2c4b (&priv->state_lock){+.+.}, at: mlx5e_close+0x29/0x60
[mlx5_core]
[ 342.531642] #3: 0000000060c5bde3 (mem_id_lock){+.+.}, at: xdp_rxq_info_unreg+0x93/0x6b0
[ 342.541206]
[ 342.541206] stack backtrace:
[ 342.547075] CPU: 12 PID: 3934 Comm: modprobe Tainted: G O 4.18.0-rc2+ #17
[ 342.556621] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
[ 342.565606] Call Trace:
[ 342.568861] dump_stack+0x78/0xb3
[ 342.573086] xdp_rxq_info_unreg+0x3f5/0x6b0
[ 342.578285] ? __call_rcu+0x220/0x300
[ 342.582911] mlx5e_free_rq+0x38/0xc0 [mlx5_core]
[ 342.588602] mlx5e_close_channel+0x20/0x120 [mlx5_core]
[ 342.594976] mlx5e_close_channels+0x26/0x40 [mlx5_core]
[ 342.601345] mlx5e_close_locked+0x44/0x50 [mlx5_core]
[ 342.607519] mlx5e_close+0x42/0x60 [mlx5_core]
[ 342.613005] __dev_close_many+0xb1/0x120
[ 342.617911] dev_close_many+0xa2/0x170
[ 342.622622] rollback_registered_many+0x148/0x460
[ 342.628401] ? __lock_acquire+0x48d/0x11b0
[ 342.633498] ? unregister_netdev+0xe/0x20
[ 342.638495] rollback_registered+0x56/0x90
[ 342.643588] unregister_netdevice_queue+0x7e/0x100
[ 342.649461] unregister_netdev+0x18/0x20
[ 342.654362] mlx5e_remove+0x2a/0x50 [mlx5_core]
[ 342.659944] mlx5_remove_device+0xe5/0x110 [mlx5_core]
[ 342.666208] mlx5_unregister_interface+0x39/0x90 [mlx5_core]
[ 342.673038] cleanup+0x5/0xbfc [mlx5_core]
[ 342.678094] __x64_sys_delete_module+0x16b/0x240
[ 342.683725] ? do_syscall_64+0x1c/0x210
[ 342.688476] do_syscall_64+0x5a/0x210
[ 342.693025] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/xdp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 9d1f22072d5d..c20fefbfb76c 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -102,7 +102,9 @@ static void __xdp_rxq_info_unreg_mem_model(struct xdp_rxq_info *xdp_rxq)
mutex_lock(&mem_id_lock);
+ rcu_read_lock();
xa = rhashtable_lookup(mem_id_ht, &id, mem_id_rht_params);
+ rcu_read_unlock();
if (!xa) {
mutex_unlock(&mem_id_lock);
return;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] net/mlx5e: Move mlx5e_priv_flags into en_ethtool.c
From: Saeed Mahameed @ 2018-07-17 15:00 UTC (permalink / raw)
To: Kamal Heib; +Cc: David S . Miller, Saeed Mahameed, Linux Netdev List
In-Reply-To: <20180715190628.23508-1-kamalheib1@gmail.com>
On Sun, Jul 15, 2018 at 12:06 PM, Kamal Heib <kamalheib1@gmail.com> wrote:
> Move the definition of mlx5e_priv_flags into en_ethtool.c because it's
> only used there.
>
> Fixes: 4e59e2888139 ("net/mlx5e: Introduce net device priv flags infrastructure")
> Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
> ---
LGTM, but why to net ?
this patch should go to net-next.
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 7 -------
> drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 7 +++++++
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index eb9eb7aa953a..84e6a5b42286 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -208,13 +208,6 @@ struct mlx5e_umr_wqe {
>
> extern const char mlx5e_self_tests[][ETH_GSTRING_LEN];
>
> -static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
> - "rx_cqe_moder",
> - "tx_cqe_moder",
> - "rx_cqe_compress",
> - "rx_striding_rq",
> -};
> -
> enum mlx5e_priv_flag {
> MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
> MLX5E_PFLAG_TX_CQE_BASED_MODER = (1 << 1),
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> index fffe514ba855..2a1c35d82c2e 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> @@ -33,6 +33,13 @@
> #include "en.h"
> #include "en/port.h"
>
> +static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
> + "rx_cqe_moder",
> + "tx_cqe_moder",
> + "rx_cqe_compress",
> + "rx_striding_rq",
> +};
> +
> void mlx5e_ethtool_get_drvinfo(struct mlx5e_priv *priv,
> struct ethtool_drvinfo *drvinfo)
> {
> --
> 2.14.4
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Remove unused address-cells/size-cells of dwmac-sun8i
From: Maxime Ripard @ 2018-07-17 15:19 UTC (permalink / raw)
To: Corentin Labbe
Cc: catalin.marinas-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
wens-jdAy2FN1RRM, will.deacon-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1531655749-14063-1-git-send-email-clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Sun, Jul 15, 2018 at 11:55:49AM +0000, Corentin Labbe wrote:
> address-cells/size-cells is unnecessary for dwmac-sun8i node.
> It was in early days, but since a mdio node is used, it could be
> removed.
>
> This patch fix the following DT warning:
> Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Corentin Labbe <clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 8 --------
> arch/arm/boot/dts/sun8i-a83t.dtsi | 2 --
> arch/arm/boot/dts/sun8i-r40.dtsi | 2 --
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 --
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 --
Just saw this, and dropped the patch. Please provide separate patches
for the h3-h5 DTSI, the arm64 and arm patches.
And ideally for the binding.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 1/6] batman-adv: Fix bat_ogm_iv best gw refcnt after netlink dump
From: Simon Wunderlich @ 2018-07-17 15:19 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20180717151946.31900-1-sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
A reference for the best gateway is taken when the list of gateways in the
mesh is sent via netlink. This is necessary to check whether the currently
dumped entry is the currently selected gateway or not. This information is
then transferred as flag BATADV_ATTR_FLAG_BEST.
After the comparison of the current entry is done,
batadv_iv_gw_dump_entry() has to decrease the reference counter again.
Otherwise the reference will be held and thus prevents a proper shutdown of
the batman-adv interfaces (and some of the interfaces enslaved in it).
Fixes: efb766af06e3 ("batman-adv: add B.A.T.M.A.N. IV bat_gw_dump implementations")
Reported-by: Andreas Ziegler <dev-ARtvInVfO7m7XaAKMTL6PIQuADTiUCJX@public.gmane.org>
Tested-by: Andreas Ziegler <dev-ARtvInVfO7m7XaAKMTL6PIQuADTiUCJX@public.gmane.org>
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Acked-by: Marek Lindner <mareklindner-rVWd3aGhH2z5bpWLKbzFeg@public.gmane.org>
Signed-off-by: Simon Wunderlich <sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
---
net/batman-adv/bat_iv_ogm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c
index be09a9883825..73bf6a93a3cf 100644
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -2732,7 +2732,7 @@ static int batadv_iv_gw_dump_entry(struct sk_buff *msg, u32 portid, u32 seq,
{
struct batadv_neigh_ifinfo *router_ifinfo = NULL;
struct batadv_neigh_node *router;
- struct batadv_gw_node *curr_gw;
+ struct batadv_gw_node *curr_gw = NULL;
int ret = 0;
void *hdr;
@@ -2780,6 +2780,8 @@ static int batadv_iv_gw_dump_entry(struct sk_buff *msg, u32 portid, u32 seq,
ret = 0;
out:
+ if (curr_gw)
+ batadv_gw_node_put(curr_gw);
if (router_ifinfo)
batadv_neigh_ifinfo_put(router_ifinfo);
if (router)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: sunxi: Remove unused address-cells/size-cells of dwmac-sun8i
From: Maxime Ripard @ 2018-07-17 15:18 UTC (permalink / raw)
To: Corentin Labbe
Cc: catalin.marinas-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
wens-jdAy2FN1RRM, will.deacon-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1531655749-14063-1-git-send-email-clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Sun, Jul 15, 2018 at 11:55:49AM +0000, Corentin Labbe wrote:
> address-cells/size-cells is unnecessary for dwmac-sun8i node.
> It was in early days, but since a mdio node is used, it could be
> removed.
>
> This patch fix the following DT warning:
> Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Corentin Labbe <clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next] net: cavium: add missing PCI dependencies
From: Andrew Lunn @ 2018-07-17 15:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Aleksey Makarov, Radoslaw Biernacki,
Felix Manlunas, Sunil Goutham, Vijaya Mohan Guvva,
Alexander Sverdlin, netdev, linux-kernel
In-Reply-To: <20180717134756.3447762-1-arnd@arndb.de>
On Tue, Jul 17, 2018 at 03:46:34PM +0200, Arnd Bergmann wrote:
> While some of the cavium drivers don't require PCI support, most
> others do, as shown by these build failures:
Hi Arnd
FYI
There is a 0-day email about mdio-thunder.c also failing. It looks
like a missing PCI dependency as well, although i cannot find the
patch which removed the existing dependency.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: cavium: add missing PCI dependencies
From: Alexander Sverdlin @ 2018-07-17 14:31 UTC (permalink / raw)
To: Arnd Bergmann, David S. Miller
Cc: Aleksey Makarov, Radoslaw Biernacki, Felix Manlunas,
Sunil Goutham, Vijaya Mohan Guvva, netdev, linux-kernel
In-Reply-To: <20180717134756.3447762-1-arnd@arndb.de>
Hello Arnd,
On 17/07/18 15:46, Arnd Bergmann wrote:
> While some of the cavium drivers don't require PCI support, most
> others do, as shown by these build failures:
[...]
> This adds back the minimum set of dependencies to get everything to
> build cleanly again, but leaving the ones that build cleanly.
>
> Fixes: 7e2bc7fb65d5 ("net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/cavium/Kconfig | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig
> index 4c3a5c354497..80e2e93e4aad 100644
> --- a/drivers/net/ethernet/cavium/Kconfig
> +++ b/drivers/net/ethernet/cavium/Kconfig
> @@ -14,7 +14,7 @@ if NET_VENDOR_CAVIUM
>
> config THUNDER_NIC_PF
> tristate "Thunder Physical function driver"
> - depends on 64BIT
> + depends on 64BIT && PCI
> select THUNDER_NIC_BGX
> ---help---
> This driver supports Thunder's NIC physical function.
> @@ -27,7 +27,7 @@ config THUNDER_NIC_PF
> config THUNDER_NIC_VF
> tristate "Thunder Virtual function driver"
> imply CAVIUM_PTP
> - depends on 64BIT
> + depends on 64BIT && PCI
> ---help---
> This driver supports Thunder's NIC virtual function
>
> @@ -35,7 +35,7 @@ config THUNDER_NIC_BGX
> tristate "Thunder MAC interface driver (BGX)"
> depends on 64BIT
> select PHYLIB
> - select MDIO_THUNDER
> + select MDIO_THUNDER if PCI
> select THUNDER_NIC_RGX
> ---help---
> This driver supports programming and controlling of MAC
I believe this hunk should look exactly as the previous one, i.e. 64BIT && PCI,
BGX itself depends on PCI as well. I've actually sent v2 to fix the above, but
got no reply on it up to now...
--
Best regards,
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v2 06/17] y2038: Change sys_utimensat() to use __kernel_timespec
From: Arnd Bergmann @ 2018-07-17 14:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Thomas Gleixner, y2038 Mailman List, Linux API, linux-arch,
GNU C Library, Albert ARIBAUD, Networking, Al Viro,
Peter Zijlstra, Darren Hart, Eric W . Biederman,
Dominik Brodowski
In-Reply-To: <20180717125243.GE25416@infradead.org>
On Tue, Jul 17, 2018 at 2:52 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
>> When 32-bit architectures get changed to support 64-bit time_t,
>> utimensat() needs to use the new __kernel_timespec structure as its
>> argument.
>>
>> The older utime(), utimes() and futimesat() system calls don't need a
>> corresponding change as they are no longer used on C libraries that have
>> 64-bit time support.
>>
>> As we do for the other syscalls that have timespec arguments, we reuse
>> the 'compat' syscall entry points to implement the traditional four
>> interfaces, and only leave the new utimensat() as a native handler,
>> so that the same code gets used on both 32-bit and 64-bit kernels
>> on each syscall.
>
> I wonder about the direction here: wouldn't it be easier to just
> leave th existing syscall names as-is and introduce a new utimesat64
> which uses the new timespec? We can then drop the old legacy utimesat
> for new architectures added after the cutover.
We have debated both approaches over several years, but for
most syscalls, we picked the approach described above, for multiple
reasons:
- For any system call that takes a time_t derived argument, we
already have two implementations (native and compat), so adding a
third one requires duplicating some code.
- I want to avoid adding an implementation that is not well tested
if possible, to make it less likely to introduce security holes or
subtle bugs that we can't fix later without breaking the ABI.
Using the same implementation for the new 32-bit case that
we have for the existing 64-bit case means that this code is
much better exercised, while reusing the compat code for the
traditional native syscall means it gets exercised by all current
user space, which makes it more likely to catch bugs early.
- Looking at the end result, I find it more logical to have each
of the converted syscalls implement the same binary interface
on both 32-bit and 64-bit architectures with the same code,
and have the old 32-bit implementation be similarly shared.
This is even more important once we add new architectures
that don't even provide the 32-bit time_t interfaces and just
leave out the old entry points.
Arnd
^ permalink raw reply
* Re: [PATCH net] netfilter: nf_conntrack: prevent uninit-value in gc_worker
From: Dmitry Vyukov @ 2018-07-17 14:26 UTC (permalink / raw)
To: Florian Westphal
Cc: Eric Dumazet, Eric Dumazet, Pablo Neira Ayuso, Jozsef Kadlecsik,
netfilter-devel, netdev
In-Reply-To: <CACT4Y+bMbU=hjhafhu2foGzz3poeH364859PaDeS2_rqPsKtGg@mail.gmail.com>
On Tue, Jul 17, 2018 at 4:13 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Jul 17, 2018 at 3:59 PM, Florian Westphal <fw@strlen.de> wrote:
>> Dmitry Vyukov <dvyukov@google.com> wrote:
>>> What should have been initialized it?
>>
>> nf_ct_refresh_acct()
>>
>>> I assume it should have been happened in between init_conntrack and
>>> nf_conntrack_confirm, because nf_conntrack_confirm already adds to an
>>> uninit timeout value.
>>
>> Yes.
>>
>>> Since we got only 3 such reports and no reproducer, I would suspect
>>> that there is some race involved. Is it possible that timeout
>>> initialization (presumably a call to nf_ct_refresh_acct) happens after
>>> and non-atomically with the corresponding connection state update, so
>>> that the call to nf_conntrack_confirm sneaks before it?
>>
>> Unconfirmed conntrack isn't in the hash table, so all events should
>> occur in order on same cpu:
>> 1. allocation (init_conntrack)
>> 2. timeout initialisation (via l4 tracker, can be generic one too)
>> 3. nf_conntrack_confirm (insertion in hash table)
>>
>> What could be possible is that another core is registering/unregistering
>> the conntrack hooks in parallel, I guess in that case we could have:
>>
>> 1. allocation (init_conntrack)
>> (other cpu: remove conntrack hooks)
>> (other cpu: add conntrack hooks)
>> 3. nf_conntrack_confirm (insertion in hash table)
>>
>> Just a theory of course.
>> In any case patch looks good to me.
>
>
>
> We also got 30 of the following reports, which look quite similar.
> That bug also have 2 reproducers, but they look more or less as just
> sending a packet:
>
> # See https://goo.gl/kgGztJ for information about syzkaller reproducers.
> #{"threaded":true,"repeat":true,"procs":8,"sandbox":"","fault_call":-1}
> r0 = socket$inet6(0xa, 0x3, 0x20000000021)
> sendto$inet6(r0, &(0x7f0000000000), 0xfedf, 0x0,
> &(0x7f0000000180)={0xa, 0x0, 0x0, @local={0xfe, 0x80, [], 0xaa}},
> 0x1a)
> openat$snapshot(0xffffffffffffff9c,
> &(0x7f0000000000)='/dev/snapshot\x00', 0xa0000, 0x0)
>
>
> # See https://goo.gl/kgGztJ for information about syzkaller reproducers.
> #{"repeat":true,"procs":1,"sandbox":"none","fault_call":-1,"netdev":true}
> r0 = socket$inet6(0xa, 0x3, 0x3c)
> connect$inet6(r0, &(0x7f0000000180)={0xa, 0x0, 0x0, @remote={0xfe,
> 0x80, [], 0xbb}, 0x9}, 0x1c)
> sendto$inet6(r0, &(0x7f0000000200)='!', 0x1, 0x8000, 0x0, 0x0)
> sendmsg(r0, &(0x7f0000000040)={0x0, 0x0,
> &(0x7f0000000080)=[{&(0x7f0000000300)="119a0e63c9476288b671afdbd53a5994e137381f62021d1951b627b8dda57a5d17d744648c81c5703ed8146ab1b0171f89091b1dd323ff07dbb633fb3804849f7768e586df460963245dedb4013ee555af99499e44ad420dbf65fd46fbc9ba1274429e2d5783751815828ec8cb3553110cca66460215353d19f6d8bbd8fb08ad0491634ac2fd10e2cd30bcd7fede24263a7fff16e53ea293f3551b7147c33a44ea437fb1f77f94db4e65807582990a0a5efddf12de3caea6611173f964de99645e2c02bef138b406ca0644146ae4bb91e0438f8c47beddb0ed22f56bc0851def35824ca6c7258c",
> 0xe7}], 0x1, &(0x7f0000003b40)}, 0x0)
>
>
>
>
>
> ==================================================================
> BUG: KMSAN: uninit-value in ____nf_conntrack_find
> net/netfilter/nf_conntrack_core.c:539 [inline]
> BUG: KMSAN: uninit-value in __nf_conntrack_find_get+0xc15/0x2190
> net/netfilter/nf_conntrack_core.c:573
> CPU: 0 PID: 4610 Comm: syz-executor884 Not tainted 4.18.0-rc4+ #24
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x185/0x1e0 lib/dump_stack.c:113
> kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
> __msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
> ____nf_conntrack_find net/netfilter/nf_conntrack_core.c:539 [inline]
> __nf_conntrack_find_get+0xc15/0x2190 net/netfilter/nf_conntrack_core.c:573
> resolve_normal_ct net/netfilter/nf_conntrack_core.c:1331 [inline]
> nf_conntrack_in+0x1674/0x2070 net/netfilter/nf_conntrack_core.c:1416
> ipv6_conntrack_local+0xc3/0xf0
> net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
> nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
> nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
> nf_hook include/linux/netfilter.h:242 [inline]
> __ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
> ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
> ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
> ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
> rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
> rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
> inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:641 [inline]
> sock_sendmsg net/socket.c:651 [inline]
> __sys_sendto+0x798/0x8e0 net/socket.c:1797
> __do_sys_sendto net/socket.c:1809 [inline]
> __se_sys_sendto net/socket.c:1805 [inline]
> __x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
> do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> RIP: 0033:0x4459c9
> Code: e8 bc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 0f 83 2b 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fa03df22d98 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
> RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004459c9
> RDX: 000000000000fedf RSI: 0000000020000000 RDI: 0000000000000004
> RBP: 0000000000000000 R08: 0000000020000180 R09: 000000000000001a
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006dac20
> R13: 616e732f7665642f R14: 00007fa03df239c0 R15: 0000000000000001
>
> Uninit was stored to memory at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
> kmsan_save_stack mm/kmsan/kmsan.c:271 [inline]
> kmsan_internal_chain_origin+0x13c/0x240 mm/kmsan/kmsan.c:683
> __msan_chain_origin+0x76/0xd0 mm/kmsan/kmsan_instr.c:483
> __nf_conntrack_confirm+0x2700/0x3f70 net/netfilter/nf_conntrack_core.c:793
> nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:71 [inline]
> ipv6_confirm+0x573/0x740 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:165
> nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
> nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
> nf_hook include/linux/netfilter.h:242 [inline]
> NF_HOOK_COND include/linux/netfilter.h:275 [inline]
> ip6_output+0x37d/0x710 net/ipv6/ip6_output.c:171
> dst_output include/net/dst.h:444 [inline]
> ip6_local_out+0x164/0x1d0 net/ipv6/output_core.c:176
> ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
> ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
> rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
> rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
> inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:641 [inline]
> sock_sendmsg net/socket.c:651 [inline]
> __sys_sendto+0x798/0x8e0 net/socket.c:1797
> __do_sys_sendto net/socket.c:1809 [inline]
> __se_sys_sendto net/socket.c:1805 [inline]
> __x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
> do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
>
> Uninit was created at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
> kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:181
> kmsan_kmalloc+0xa1/0x120 mm/kmsan/kmsan_hooks.c:91
> kmem_cache_alloc+0xad2/0xbb0 mm/slub.c:2739
> __nf_conntrack_alloc+0x166/0x670 net/netfilter/nf_conntrack_core.c:1137
> init_conntrack+0x635/0x2840 net/netfilter/nf_conntrack_core.c:1219
> resolve_normal_ct net/netfilter/nf_conntrack_core.c:1333 [inline]
> nf_conntrack_in+0x1812/0x2070 net/netfilter/nf_conntrack_core.c:1416
> ipv6_conntrack_local+0xc3/0xf0
> net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
> nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
> nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
> nf_hook include/linux/netfilter.h:242 [inline]
> __ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
> ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
> ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
> ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
> rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
> rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
> inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:641 [inline]
> sock_sendmsg net/socket.c:651 [inline]
> __sys_sendto+0x798/0x8e0 net/socket.c:1797
> __do_sys_sendto net/socket.c:1809 [inline]
> __se_sys_sendto net/socket.c:1805 [inline]
> __x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
> do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> ==================================================================
Here is that bug:
https://syzkaller.appspot.com/bug?extid=6f18401420df260e37ed
https://groups.google.com/forum/#!msg/syzkaller-bugs/F7KnbAmMa7E/VSbaYHyQCAAJ
^ permalink raw reply
* Re: [PATCH v2 02/17] y2038: Remove newstat family from default syscall set
From: Arnd Bergmann @ 2018-07-17 14:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Thomas Gleixner, y2038 Mailman List, Linux API, linux-arch,
GNU C Library, Albert ARIBAUD, Networking, Al Viro,
Peter Zijlstra, Darren Hart, Eric W . Biederman,
Dominik Brodowski
In-Reply-To: <20180717125039.GB25416@infradead.org>
On Tue, Jul 17, 2018 at 2:50 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Jul 16, 2018 at 06:10:48PM +0200, Arnd Bergmann wrote:
>> We have four generations of stat() syscalls:
>> - the oldstat syscalls that are only used on the older architectures
>> - the newstat family that is used on all 64-bit architectures but
>> lacked support for large files on 32-bit architectures.
>> - the stat64 family that is used mostly on 32-bit architectures to
>> replace newstat
>> - statx() to replace all of the above, adding 64-bit timestamps among
>> other things.
>>
>> We already compile stat64 only on those architectures that need it,
>> but newstat is always built, including on those that don't reference
>> it. This adds a new __ARCH_WANT_NEW_STAT symbol along the lines of
>> __ARCH_WANT_OLD_STAT and __ARCH_WANT_STAT64 to control compilation of
>> newstat. All architectures that need it use an explict define, the
>> others now get a little bit smaller, and future architecture (including
>> 64-bit targets) won't ever see it.
>>
>> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Do I read this right that you only want to provide statx by default?
Yes, that is correct.
> It is a little different from the traditional stat calls, so I'd like
> to know this is actually ok from libc folks first.
That would definitely help. See below for the stat implementation
I did in my musl libc prototype based on statx(). It passes the
LTP syscall tests, but that doesn't mean all the corner cases
are correct.
Arnd
diff --git a/src/stat/fstat.c b/src/stat/fstat.c
index ab4afc0..b4f2027 100644
--- a/src/stat/fstat.c
+++ b/src/stat/fstat.c
@@ -1,3 +1,4 @@
+#define _BSD_SOURCE
#include <sys/stat.h>
#include <errno.h>
#include <fcntl.h>
@@ -8,6 +9,9 @@ void __procfdname(char *, unsigned);
int fstat(int fd, struct stat *st)
{
+#ifdef __USE_TIME_BITS64
+ return __statx(fd, "", st, AT_EMPTY_PATH | AT_STATX_SYNC_AS_STAT);
+#else
int ret = __syscall(SYS_fstat, fd, st);
if (ret != -EBADF || __syscall(SYS_fcntl, fd, F_GETFD) < 0)
return __syscall_ret(ret);
@@ -19,6 +23,7 @@ int fstat(int fd, struct stat *st)
#else
return syscall(SYS_fstatat, AT_FDCWD, buf, st, 0);
#endif
+#endif
}
LFS64(fstat);
diff --git a/src/stat/fstatat.c b/src/stat/fstatat.c
index 863d526..80add64 100644
--- a/src/stat/fstatat.c
+++ b/src/stat/fstatat.c
@@ -1,10 +1,53 @@
+#define _BSD_SOURCE
#include <sys/stat.h>
+#include <statx.h>
+#include <fcntl.h>
+#include <errno.h>
#include "syscall.h"
#include "libc.h"
+#ifdef __USE_TIME_BITS64
+
+#define AT_FLAGS (AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | AT_EMPTY_PATH)
+
+int __statx(int fd, const char *restrict path, struct stat *restrict
buf, int flag)
+{
+ struct statx stx;
+ int ret;
+
+ ret = syscall(SYS_statx, fd, path, flag, STATX_BASIC_STATS, &stx);
+
+ buf->st_dev = (dev_t)stx.stx_dev_major << 32 | stx.stx_dev_minor;
+ buf->st_ino = stx.stx_ino;
+ buf->st_mode = stx.stx_mode;
+ buf->st_nlink = stx.stx_nlink;
+ buf->st_uid = stx.stx_uid;
+ buf->st_gid = stx.stx_gid;
+ buf->st_rdev = (dev_t)stx.stx_rdev_major << 32 | stx.stx_rdev_minor;
+ buf->st_size = stx.stx_size;
+ buf->st_blksize = stx.stx_blksize;
+ buf->st_blocks = stx.stx_blocks;
+ buf->st_atim.tv_sec = stx.stx_atime.tv_sec;
+ buf->st_mtim.tv_sec = stx.stx_atime.tv_sec;
+ buf->st_ctim.tv_sec = stx.stx_atime.tv_sec;
+ buf->st_atim.tv_nsec = stx.stx_atime.tv_nsec;
+ buf->st_mtim.tv_nsec = stx.stx_atime.tv_nsec;
+ buf->st_ctim.tv_nsec = stx.stx_atime.tv_nsec;
+
+ return ret;
+}
+#endif
+
int fstatat(int fd, const char *restrict path, struct stat *restrict
buf, int flag)
{
+#ifdef __USE_TIME_BITS64
+ if (flag & ~AT_FLAGS)
+ return __syscall_ret(-EINVAL);
+
+ return __statx(fd, path, buf, flag);
+#else
return syscall(SYS_fstatat, fd, path, buf, flag);
+#endif
}
LFS64(fstatat);
diff --git a/src/stat/lstat.c b/src/stat/lstat.c
index 5e8b84f..ad2bddd 100644
--- a/src/stat/lstat.c
+++ b/src/stat/lstat.c
@@ -1,3 +1,4 @@
+#define _BSD_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include "syscall.h"
@@ -5,7 +6,9 @@
int lstat(const char *restrict path, struct stat *restrict buf)
{
-#ifdef SYS_lstat
+#ifdef __USE_TIME_BITS64
+ return __statx(AT_FDCWD, path, buf, AT_SYMLINK_NOFOLLOW |
AT_STATX_SYNC_AS_STAT);
+#elif defined(SYS_lstat)
return syscall(SYS_lstat, path, buf);
#else
return syscall(SYS_fstatat, AT_FDCWD, path, buf, AT_SYMLINK_NOFOLLOW);
diff --git a/src/stat/stat.c b/src/stat/stat.c
index b4433a0..599903a 100644
--- a/src/stat/stat.c
+++ b/src/stat/stat.c
@@ -1,3 +1,4 @@
+#define _BSD_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include "syscall.h"
@@ -5,7 +6,9 @@
int stat(const char *restrict path, struct stat *restrict buf)
{
-#ifdef SYS_stat
+#ifdef __USE_TIME_BITS64
+ return __statx(AT_FDCWD, path, buf, AT_STATX_SYNC_AS_STAT);
+#elif defined(SYS_stat)
return syscall(SYS_stat, path, buf);
#else
return syscall(SYS_fstatat, AT_FDCWD, path, buf, 0);
^ permalink raw reply related
* Re: [PATCH net] netfilter: nf_conntrack: prevent uninit-value in gc_worker
From: Dmitry Vyukov @ 2018-07-17 14:13 UTC (permalink / raw)
To: Florian Westphal
Cc: Eric Dumazet, Eric Dumazet, Pablo Neira Ayuso, Jozsef Kadlecsik,
netfilter-devel, netdev
In-Reply-To: <20180717135931.dexnlxtnv3daunit@breakpoint.cc>
On Tue, Jul 17, 2018 at 3:59 PM, Florian Westphal <fw@strlen.de> wrote:
> Dmitry Vyukov <dvyukov@google.com> wrote:
>> What should have been initialized it?
>
> nf_ct_refresh_acct()
>
>> I assume it should have been happened in between init_conntrack and
>> nf_conntrack_confirm, because nf_conntrack_confirm already adds to an
>> uninit timeout value.
>
> Yes.
>
>> Since we got only 3 such reports and no reproducer, I would suspect
>> that there is some race involved. Is it possible that timeout
>> initialization (presumably a call to nf_ct_refresh_acct) happens after
>> and non-atomically with the corresponding connection state update, so
>> that the call to nf_conntrack_confirm sneaks before it?
>
> Unconfirmed conntrack isn't in the hash table, so all events should
> occur in order on same cpu:
> 1. allocation (init_conntrack)
> 2. timeout initialisation (via l4 tracker, can be generic one too)
> 3. nf_conntrack_confirm (insertion in hash table)
>
> What could be possible is that another core is registering/unregistering
> the conntrack hooks in parallel, I guess in that case we could have:
>
> 1. allocation (init_conntrack)
> (other cpu: remove conntrack hooks)
> (other cpu: add conntrack hooks)
> 3. nf_conntrack_confirm (insertion in hash table)
>
> Just a theory of course.
> In any case patch looks good to me.
We also got 30 of the following reports, which look quite similar.
That bug also have 2 reproducers, but they look more or less as just
sending a packet:
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"threaded":true,"repeat":true,"procs":8,"sandbox":"","fault_call":-1}
r0 = socket$inet6(0xa, 0x3, 0x20000000021)
sendto$inet6(r0, &(0x7f0000000000), 0xfedf, 0x0,
&(0x7f0000000180)={0xa, 0x0, 0x0, @local={0xfe, 0x80, [], 0xaa}},
0x1a)
openat$snapshot(0xffffffffffffff9c,
&(0x7f0000000000)='/dev/snapshot\x00', 0xa0000, 0x0)
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"repeat":true,"procs":1,"sandbox":"none","fault_call":-1,"netdev":true}
r0 = socket$inet6(0xa, 0x3, 0x3c)
connect$inet6(r0, &(0x7f0000000180)={0xa, 0x0, 0x0, @remote={0xfe,
0x80, [], 0xbb}, 0x9}, 0x1c)
sendto$inet6(r0, &(0x7f0000000200)='!', 0x1, 0x8000, 0x0, 0x0)
sendmsg(r0, &(0x7f0000000040)={0x0, 0x0,
&(0x7f0000000080)=[{&(0x7f0000000300)="119a0e63c9476288b671afdbd53a5994e137381f62021d1951b627b8dda57a5d17d744648c81c5703ed8146ab1b0171f89091b1dd323ff07dbb633fb3804849f7768e586df460963245dedb4013ee555af99499e44ad420dbf65fd46fbc9ba1274429e2d5783751815828ec8cb3553110cca66460215353d19f6d8bbd8fb08ad0491634ac2fd10e2cd30bcd7fede24263a7fff16e53ea293f3551b7147c33a44ea437fb1f77f94db4e65807582990a0a5efddf12de3caea6611173f964de99645e2c02bef138b406ca0644146ae4bb91e0438f8c47beddb0ed22f56bc0851def35824ca6c7258c",
0xe7}], 0x1, &(0x7f0000003b40)}, 0x0)
==================================================================
BUG: KMSAN: uninit-value in ____nf_conntrack_find
net/netfilter/nf_conntrack_core.c:539 [inline]
BUG: KMSAN: uninit-value in __nf_conntrack_find_get+0xc15/0x2190
net/netfilter/nf_conntrack_core.c:573
CPU: 0 PID: 4610 Comm: syz-executor884 Not tainted 4.18.0-rc4+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1e0 lib/dump_stack.c:113
kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
__msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
____nf_conntrack_find net/netfilter/nf_conntrack_core.c:539 [inline]
__nf_conntrack_find_get+0xc15/0x2190 net/netfilter/nf_conntrack_core.c:573
resolve_normal_ct net/netfilter/nf_conntrack_core.c:1331 [inline]
nf_conntrack_in+0x1674/0x2070 net/netfilter/nf_conntrack_core.c:1416
ipv6_conntrack_local+0xc3/0xf0
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
__ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x4459c9
Code: e8 bc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 2b 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa03df22d98 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004459c9
RDX: 000000000000fedf RSI: 0000000020000000 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000020000180 R09: 000000000000001a
R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006dac20
R13: 616e732f7665642f R14: 00007fa03df239c0 R15: 0000000000000001
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:271 [inline]
kmsan_internal_chain_origin+0x13c/0x240 mm/kmsan/kmsan.c:683
__msan_chain_origin+0x76/0xd0 mm/kmsan/kmsan_instr.c:483
__nf_conntrack_confirm+0x2700/0x3f70 net/netfilter/nf_conntrack_core.c:793
nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:71 [inline]
ipv6_confirm+0x573/0x740 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:165
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK_COND include/linux/netfilter.h:275 [inline]
ip6_output+0x37d/0x710 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
ip6_local_out+0x164/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0xa1/0x120 mm/kmsan/kmsan_hooks.c:91
kmem_cache_alloc+0xad2/0xbb0 mm/slub.c:2739
__nf_conntrack_alloc+0x166/0x670 net/netfilter/nf_conntrack_core.c:1137
init_conntrack+0x635/0x2840 net/netfilter/nf_conntrack_core.c:1219
resolve_normal_ct net/netfilter/nf_conntrack_core.c:1333 [inline]
nf_conntrack_in+0x1812/0x2070 net/netfilter/nf_conntrack_core.c:1416
ipv6_conntrack_local+0xc3/0xf0
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
__ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
^ permalink raw reply
* photoshop work for
From: Ruby @ 2018-07-17 9:46 UTC (permalink / raw)
To: netdev
We have got a team of professional to do image editing service for you.
We have 20 image editors and on daily basis 2000 images can be processed.
If you want to check our quality of work please send us a photo with
instruction and we will work on it.
Our Services:
Photo cut out, masking, clipping path
Color, brightness and contrast correction
Beauty, Model retouching, skin retouching
Image cropping and resizing
Correcting the shape and size
We do unlimited revisions until you are satisfied with the work.
Thanks,
Ruby Young
^ permalink raw reply
* Re: [PATCH net] netfilter: nf_conntrack: prevent uninit-value in gc_worker
From: Florian Westphal @ 2018-07-17 13:59 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Eric Dumazet, Florian Westphal, Eric Dumazet, Pablo Neira Ayuso,
Jozsef Kadlecsik, netfilter-devel, netdev
In-Reply-To: <CACT4Y+buOFu2CLkGoqupQSHYpuxDsUPPdfSmpDa_6Sht9LesTQ@mail.gmail.com>
Dmitry Vyukov <dvyukov@google.com> wrote:
> What should have been initialized it?
nf_ct_refresh_acct()
> I assume it should have been happened in between init_conntrack and
> nf_conntrack_confirm, because nf_conntrack_confirm already adds to an
> uninit timeout value.
Yes.
> Since we got only 3 such reports and no reproducer, I would suspect
> that there is some race involved. Is it possible that timeout
> initialization (presumably a call to nf_ct_refresh_acct) happens after
> and non-atomically with the corresponding connection state update, so
> that the call to nf_conntrack_confirm sneaks before it?
Unconfirmed conntrack isn't in the hash table, so all events should
occur in order on same cpu:
1. allocation (init_conntrack)
2. timeout initialisation (via l4 tracker, can be generic one too)
3. nf_conntrack_confirm (insertion in hash table)
What could be possible is that another core is registering/unregistering
the conntrack hooks in parallel, I guess in that case we could have:
1. allocation (init_conntrack)
(other cpu: remove conntrack hooks)
(other cpu: add conntrack hooks)
3. nf_conntrack_confirm (insertion in hash table)
Just a theory of course.
In any case patch looks good to me.
^ permalink raw reply
* KMSAN: uninit-value in __nf_conntrack_find_get
From: syzbot @ 2018-07-17 14:25 UTC (permalink / raw)
To: coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: b64f7ec04e12 kmsan: implement kmsan_memmove_shadow() and k..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=109869d0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=93d57043084eee38
dashboard link: https://syzkaller.appspot.com/bug?extid=6f18401420df260e37ed
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=174cce78400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16b0b562400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6f18401420df260e37ed@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: uninit-value in ____nf_conntrack_find
net/netfilter/nf_conntrack_core.c:539 [inline]
BUG: KMSAN: uninit-value in __nf_conntrack_find_get+0xc15/0x2190
net/netfilter/nf_conntrack_core.c:573
CPU: 0 PID: 4610 Comm: syz-executor884 Not tainted 4.18.0-rc4+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1e0 lib/dump_stack.c:113
kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
__msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
____nf_conntrack_find net/netfilter/nf_conntrack_core.c:539 [inline]
__nf_conntrack_find_get+0xc15/0x2190 net/netfilter/nf_conntrack_core.c:573
resolve_normal_ct net/netfilter/nf_conntrack_core.c:1331 [inline]
nf_conntrack_in+0x1674/0x2070 net/netfilter/nf_conntrack_core.c:1416
ipv6_conntrack_local+0xc3/0xf0
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
__ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x4459c9
Code: e8 bc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 2b 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa03df22d98 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004459c9
RDX: 000000000000fedf RSI: 0000000020000000 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000020000180 R09: 000000000000001a
R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006dac20
R13: 616e732f7665642f R14: 00007fa03df239c0 R15: 0000000000000001
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:271 [inline]
kmsan_internal_chain_origin+0x13c/0x240 mm/kmsan/kmsan.c:683
__msan_chain_origin+0x76/0xd0 mm/kmsan/kmsan_instr.c:483
__nf_conntrack_confirm+0x2700/0x3f70 net/netfilter/nf_conntrack_core.c:793
nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:71 [inline]
ipv6_confirm+0x573/0x740 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:165
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK_COND include/linux/netfilter.h:275 [inline]
ip6_output+0x37d/0x710 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
ip6_local_out+0x164/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0xa1/0x120 mm/kmsan/kmsan_hooks.c:91
kmem_cache_alloc+0xad2/0xbb0 mm/slub.c:2739
__nf_conntrack_alloc+0x166/0x670 net/netfilter/nf_conntrack_core.c:1137
init_conntrack+0x635/0x2840 net/netfilter/nf_conntrack_core.c:1219
resolve_normal_ct net/netfilter/nf_conntrack_core.c:1333 [inline]
nf_conntrack_in+0x1812/0x2070 net/netfilter/nf_conntrack_core.c:1416
ipv6_conntrack_local+0xc3/0xf0
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:179
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0x15d/0x3e0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
__ip6_local_out+0x64c/0x770 net/ipv6/output_core.c:164
ip6_local_out+0xa4/0x1d0 net/ipv6/output_core.c:174
ip6_send_skb net/ipv6/ip6_output.c:1696 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1716
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x45f0/0x5410 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
__sys_sendto+0x798/0x8e0 net/socket.c:1797
__do_sys_sendto net/socket.c:1809 [inline]
__se_sys_sendto net/socket.c:1805 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1805
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH] rtnetlink: fix uninitialized variable
From: Gustavo A. R. Silva @ 2018-07-17 13:43 UTC (permalink / raw)
To: Jakub Kicinski, David S. Miller; +Cc: netdev, linux-kernel, Gustavo A. R. Silva
Currently, there are execution paths in which variable err is
returned without being properly initialized previously:
1417 if (rtnl_xdp_report_one(skb, dev, &prog_id, &mode, XDP_ATTACHED_SKB,
1418 IFLA_XDP_SKB_PROG_ID, rtnl_xdp_prog_skb))
1419 goto err_cancel;
1420 if (rtnl_xdp_report_one(skb, dev, &prog_id, &mode, XDP_ATTACHED_DRV,
1421 IFLA_XDP_DRV_PROG_ID, rtnl_xdp_prog_drv))
1422 goto err_cancel;
1423 if (rtnl_xdp_report_one(skb, dev, &prog_id, &mode, XDP_ATTACHED_HW,
1424 IFLA_XDP_HW_PROG_ID, rtnl_xdp_prog_hw))
1425 goto err_cancel;
Fix this by initializing variable err to -EMSGSIZE.
Addresses-Coverity-ID: 1471831 ("Uninitialized scalar variable")
Fixes: a25717d2b604 ("xdp: support simultaneous driver and hw XDP attachment")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/core/rtnetlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e03258e..648c984 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1405,12 +1405,12 @@ static int rtnl_xdp_fill(struct sk_buff *skb, struct net_device *dev)
{
struct nlattr *xdp;
u32 prog_id;
- int err;
+ int err = -EMSGSIZE;
u8 mode;
xdp = nla_nest_start(skb, IFLA_XDP);
if (!xdp)
- return -EMSGSIZE;
+ return err;
prog_id = 0;
mode = XDP_ATTACHED_NONE;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] netfilter: nf_conntrack: prevent uninit-value in gc_worker
From: Dmitry Vyukov @ 2018-07-17 13:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: Florian Westphal, Eric Dumazet, Pablo Neira Ayuso,
Jozsef Kadlecsik, netfilter-devel, netdev
In-Reply-To: <9a877bfc-67f3-2242-a681-5814dc1c1dd4@gmail.com>
On Thu, Jul 12, 2018 at 2:11 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 07/12/2018 02:00 AM, Florian Westphal wrote:
>> Eric Dumazet <edumazet@google.com> wrote:
>>> KMSAN reported use of uninit-value in gc_worker [1]
>>>
>>> We need to clear ct->timeout in __nf_conntrack_alloc()
>>> otherwise __nf_conntrack_confirm() might propagate garbage when
>>> adding nfct_time_stamp to ct->timeout :
>>>
>>> ct->timeout += nfct_time_stamp;
>>>
>>> [1]
>>> BUG: KMSAN: uninit-value in gc_worker+0x89e/0x1530 net/netfilter/nf_conntrack_core.c:1028
>>> CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc4+ #24
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>> Workqueue: events_power_efficient gc_worker
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:77 [inline]
>>> dump_stack+0x185/0x1e0 lib/dump_stack.c:113
>>> kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
>>> __msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
>>> gc_worker+0x89e/0x1530 net/netfilter/nf_conntrack_core.c:1028
>>
>> I wonder how this can happen.
>>
>> All trackers are supposed to set ->timeout to the correct value,
>> otherwise (assuming init-to-0), we add a ct entry to global hash that
>> is expired.
>>
>> For instance, tcp calls
>> nf_ct_refresh_acct() at end of its ->packet() callback to set
>> a timeout based on the connection state.
>>
>> That being said, I don't see any harm in initing to 0 of course.
>>
>
> Yeah, unfortunately there is no repro yet, all the info I have I put it
> in the changelog.
What should have been initialized it?
I assume it should have been happened in between init_conntrack and
nf_conntrack_confirm, because nf_conntrack_confirm already adds to an
uninit timeout value.
Since we got only 3 such reports and no reproducer, I would suspect
that there is some race involved. Is it possible that timeout
initialization (presumably a call to nf_ct_refresh_acct) happens after
and non-atomically with the corresponding connection state update, so
that the call to nf_conntrack_confirm sneaks before it?
^ permalink raw reply
* [PATCH net-next] tipc: remove unused tipc_group_size
From: YueHaibing @ 2018-07-17 14:11 UTC (permalink / raw)
To: davem, jon.maloy, ying.xue
Cc: linux-kernel, netdev, tipc-discussion, YueHaibing
After commit eb929a91b213 ("tipc: improve poll() for group member socket"),
it is no longer used.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/tipc/group.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/tipc/group.c b/net/tipc/group.c
index cbe39e8..8f43e7d 100644
--- a/net/tipc/group.c
+++ b/net/tipc/group.c
@@ -159,11 +159,6 @@ u32 tipc_group_exclude(struct tipc_group *grp)
return 0;
}
-int tipc_group_size(struct tipc_group *grp)
-{
- return grp->member_cnt;
-}
-
struct tipc_group *tipc_group_create(struct net *net, u32 portid,
struct tipc_group_req *mreq,
bool *group_is_open)
--
2.7.0
^ permalink raw reply related
* RE: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Steve Wise @ 2018-07-17 13:03 UTC (permalink / raw)
To: 'Max Gurtovoy', 'Sagi Grimberg',
'Leon Romanovsky'
Cc: 'Doug Ledford', 'Jason Gunthorpe',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <3f827784-3089-2375-9feb-b3c1701d7471@mellanox.com>
> On 7/16/2018 8:08 PM, Steve Wise wrote:
> > Hey Max:
> >
> >
>
> Hey,
>
> > On 7/16/2018 11:46 AM, Max Gurtovoy wrote:
> >>
> >>
> >> On 7/16/2018 5:59 PM, Sagi Grimberg wrote:
> >>>
> >>>> Hi,
> >>>> I've tested this patch and seems problematic at this moment.
> >>>
> >>> Problematic how? what are you seeing?
> >>
> >> Connection failures and same error Steve saw:
> >>
> >> [Mon Jul 16 16:19:11 2018] nvme nvme0: Connect command failed, error
> >> wo/DNR bit: -16402
> >> [Mon Jul 16 16:19:11 2018] nvme nvme0: failed to connect queue: 2 ret=-
> 18
> >>
> >>
> >>>
> >>>> maybe this is because of the bug that Steve mentioned in the NVMe
> >>>> mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
> >>>> initiator and I'll run his suggestion as well.
> >>>
> >>> Is your device irq affinity linear?
> >>
> >> When it's linear and the balancer is stopped the patch works.
> >>
> >>>
> >>>> BTW, when I run the blk_mq_map_queues it works for every irq
> affinity.
> >>>
> >>> But its probably not aligned to the device vector affinity.
> >>
> >> but I guess it's better in some cases.
> >>
> >> I've checked the situation before Leon's patch and set all the vetcors
> >> to CPU 0. In this case (I think that this was the initial report by
> >> Steve), we use the affinity_hint (Israel's and Saeed's patches were we
> >> use dev->priv.irq_info[vector].mask) and it worked fine.
> >>
> >> Steve,
> >> Can you share your configuration (kernel, HCA, affinity map, connect
> >> command, lscpu) ?
> >> I want to repro it in my lab.
> >>
> >
> > - linux-4.18-rc1 + the nvme/nvmet inline_data_size patches + patches to
> > enable ib_get_vector_affinity() in cxgb4 + sagi's patch + leon's mlx5
> > patch so I can change the affinity via procfs.
>
> ohh, now I understand that you where complaining regarding the affinity
> change reflection to mlx5_ib_get_vector_affinity and not regarding the
> failures on connecting while the affinity overlaps (that is working good
> before Leon's patch).
> So this is a known issue since we used a static hint that never changes
> from dev->priv.irq_info[vector].mask.
>
> IMO we must fulfil the user wish to connect to N queues and not reduce
> it because of affinity overlaps. So in order to push Leon's patch we
> must also fix the blk_mq_rdma_map_queues to do a best effort mapping
> according the affinity and map the rest in naive way (in that way we
> will *always* map all the queues).
That is what I would expect also. For example, in my node, where there are
16 cpus, and 2 numa nodes, I observe much better nvmf IOPS performance by
setting up my 16 driver completion event queues such that each is bound to a
node-local cpu. So I end up with each nodel-local cpu having 2 queues bound
to it. W/O adding support in iw_cxgb4 for ib_get_vector_affinity(), this
works fine. I assumed adding ib_get_vector_affinity() would allow this to
all "just work" by default, but I'm running into this connection failure
issue.
I don't understand exactly what the blk_mq layer is trying to do, but I
assume it has ingress event queues and processing that it trying to align
with the drivers ingress cq event handling, so everybody stays on the same
cpu (or at least node). But something else is going on. Is there
documentation on how this works somewhere?
Thanks,
Steve
^ permalink raw reply
* [PATCH net-next] tipc: remove unused tipc_link_is_active
From: YueHaibing @ 2018-07-17 13:58 UTC (permalink / raw)
To: davem, jon.maloy, ying.xue
Cc: linux-kernel, netdev, tipc-discussion, YueHaibing
tipc_link_is_active is no longer used and can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/tipc/link.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index df763be..6987ffc 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -297,11 +297,6 @@ static bool link_is_bc_rcvlink(struct tipc_link *l)
return ((l->bc_rcvlink == l) && !link_is_bc_sndlink(l));
}
-int tipc_link_is_active(struct tipc_link *l)
-{
- return l->active;
-}
-
void tipc_link_set_active(struct tipc_link *l, bool active)
{
l->active = active;
--
2.7.0
^ permalink raw reply related
* KMSAN: kernel-infoleak in put_cmsg
From: syzbot @ 2018-07-17 13:23 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 123906095e30 kmsan: introduce kmsan_interrupt_enter()/kmsa..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=166dafa0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=9adb4b567003cac781f0
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=164e4ab0400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15a41e40400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9adb4b567003cac781f0@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: kernel-infoleak in copy_to_user include/linux/uaccess.h:184
[inline]
BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261
copy_to_user include/linux/uaccess.h:184 [inline]
put_cmsg+0x5ef/0x860 net/core/scm.c:242
ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
sock_common_recvmsg+0x173/0x280 net/core/sock.c:3023
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4456b9
RSP: 002b:00007f5ce4b16da8 EFLAGS: 00000297 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004456b9
RDX: 0000000000000000 RSI: 00000000200004c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000297 R12: 00000000006dac20
R13: 0000000020000500 R14: 0100000000000000 R15: 0000000000000001
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:297 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:689
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:464
ip6_datagram_recv_specific_ctl+0x1c3e/0x1eb0 net/ipv6/datagram.c:713
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
sock_common_recvmsg+0x173/0x280 net/core/sock.c:3023
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:192
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:318
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:325
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb35/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
__ip6_append_data+0x364d/0x4fb0 net/ipv6/ip6_output.c:1434
ip6_append_data+0x40e/0x6b0 net/ipv6/ip6_output.c:1597
rawv6_sendmsg+0x2756/0x4fc0 net/ipv6/raw.c:928
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Bytes 2-3 of 24 are uninitialized
Memory access starts at ffff8801bde1f8a8
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next] net/mlx5: fix an unused-function warning
From: Arnd Bergmann @ 2018-07-17 13:49 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, David S. Miller, Ilya Lesokhin,
Boris Pismenny
Cc: Arnd Bergmann, netdev, linux-rdma, linux-kernel
These dummy helpers are all intended to be inline functions,
but one of them by accident came without the 'inline' keyword,
causing a harmless warning:
In file included from drivers/net/ethernet/mellanox/mlx5/core/main.c:63:
drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h:79:1: error: 'mlx5_accel_tls_add_flow' defined but not used [-Werror=unused-function]
mlx5_accel_tls_add_flow(struct mlx5_core_dev *mdev, void *flow,
Fixes: ab412e1dd7db ("net/mlx5: Accel, add TLS rx offload routines")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h b/drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h
index 2228c1083528..def4093ebfae 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h
@@ -75,7 +75,7 @@ void mlx5_accel_tls_cleanup(struct mlx5_core_dev *mdev);
#else
-static int
+static inline int
mlx5_accel_tls_add_flow(struct mlx5_core_dev *mdev, void *flow,
struct tls_crypto_info *crypto_info,
u32 start_offload_tcp_sn, u32 *p_swid,
--
2.9.0
^ permalink raw reply related
* [PATCH net-next] net: cavium: add missing PCI dependencies
From: Arnd Bergmann @ 2018-07-17 13:46 UTC (permalink / raw)
To: David S. Miller
Cc: Arnd Bergmann, Aleksey Makarov, Radoslaw Biernacki,
Felix Manlunas, Sunil Goutham, Vijaya Mohan Guvva,
Alexander Sverdlin, netdev, linux-kernel
While some of the cavium drivers don't require PCI support, most
others do, as shown by these build failures:
WARNING: unmet direct dependencies detected for MDIO_THUNDER
Depends on [n]: NETDEVICES [=y] && MDIO_BUS [=y] && 64BIT [=y] && PCI [=n]
Selected by [y]:
- THUNDER_NIC_BGX [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_CAVIUM [=y] && 64BIT [=y]
- THUNDER_NIC_RGX [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_CAVIUM [=y] && 64BIT [=y]
drivers/net/ethernet/cavium/thunder/nicvf_main.c: In function 'nicvf_set_irq_affinity':
drivers/net/ethernet/cavium/thunder/nicvf_main.c:1095:25: error: implicit declaration of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'? [-Werror=implicit-function-declaration]
drivers/net/ethernet/cavium/thunder/nic_main.c: In function 'nic_mbx_intr_handler':
drivers/net/ethernet/cavium/thunder/nic_main.c:1135:13: error: implicit declaration of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'? [-Werror=implicit-function-declaration]
In file included from drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:27:
drivers/net/ethernet/cavium/liquidio/octeon_main.h: In function 'octeon_unmap_pci_barx':
drivers/net/ethernet/cavium/liquidio/octeon_main.h:97:3: error: implicit declaration of function 'pci_release_region'; did you mean 'pci_release_regions'? [-Werror=implicit-function-declaration]
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c: In function 'octeon_mbox_process_cmd':
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c:263:3: error: implicit declaration of function 'pcie_capability_set_word'; did you mean 'has_capability_noaudit'? [-Werror=implicit-function-declaration]
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c: In function 'setup_cn23xx_octeon_pf_device':
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1315:22: error: 'data32' is used uninitialized in this function [-Werror=uninitialized]
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c: In function 'cn23xx_dump_vf_iq_regs':
include/linux/dynamic_debug.h:135:3: error: 'regval' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/net/ethernet/cavium/liquidio/lio_core.c: In function 'octeon_setup_interrupt':
drivers/net/ethernet/cavium/liquidio/lio_core.c:1067:17: error: invalid application of 'sizeof' to incomplete type 'struct msix_entry'
drivers/net/ethernet/cavium/liquidio/octeon_main.h: In function 'octeon_unmap_pci_barx':
drivers/net/ethernet/cavium/liquidio/octeon_main.h:97:3: error: implicit declaration of function 'pci_release_region'; did you mean 'pci_release_regions'? [-Werror=implicit-function-declaration]
This adds back the minimum set of dependencies to get everything to
build cleanly again, but leaving the ones that build cleanly.
Fixes: 7e2bc7fb65d5 ("net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/cavium/Kconfig | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig
index 4c3a5c354497..80e2e93e4aad 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -14,7 +14,7 @@ if NET_VENDOR_CAVIUM
config THUNDER_NIC_PF
tristate "Thunder Physical function driver"
- depends on 64BIT
+ depends on 64BIT && PCI
select THUNDER_NIC_BGX
---help---
This driver supports Thunder's NIC physical function.
@@ -27,7 +27,7 @@ config THUNDER_NIC_PF
config THUNDER_NIC_VF
tristate "Thunder Virtual function driver"
imply CAVIUM_PTP
- depends on 64BIT
+ depends on 64BIT && PCI
---help---
This driver supports Thunder's NIC virtual function
@@ -35,7 +35,7 @@ config THUNDER_NIC_BGX
tristate "Thunder MAC interface driver (BGX)"
depends on 64BIT
select PHYLIB
- select MDIO_THUNDER
+ select MDIO_THUNDER if PCI
select THUNDER_NIC_RGX
---help---
This driver supports programming and controlling of MAC
@@ -45,7 +45,7 @@ config THUNDER_NIC_RGX
tristate "Thunder MAC interface driver (RGX)"
depends on 64BIT
select PHYLIB
- select MDIO_THUNDER
+ select MDIO_THUNDER if PCI
---help---
This driver supports configuring XCV block of RGX interface
present on CN81XX chip.
@@ -53,6 +53,7 @@ config THUNDER_NIC_RGX
config CAVIUM_PTP
tristate "Cavium PTP coprocessor as PTP clock"
depends on 64BIT
+ depends on PCI
imply PTP_1588_CLOCK
default y
---help---
@@ -66,6 +67,7 @@ config LIQUIDIO
tristate "Cavium LiquidIO support"
depends on 64BIT
depends on MAY_USE_DEVLINK
+ depends on PCI
imply PTP_1588_CLOCK
select FW_LOADER
select LIBCRC32C
--
2.9.0
^ permalink raw reply related
* Re: [PATCH v2 06/17] y2038: Change sys_utimensat() to use __kernel_timespec
From: Christoph Hellwig @ 2018-07-17 12:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: tglx, y2038, hch, linux-api, linux-arch, libc-alpha,
albert.aribaud, netdev, viro, peterz, dvhart, ebiederm, linux
In-Reply-To: <20180716161103.16239-7-arnd@arndb.de>
On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
> When 32-bit architectures get changed to support 64-bit time_t,
> utimensat() needs to use the new __kernel_timespec structure as its
> argument.
>
> The older utime(), utimes() and futimesat() system calls don't need a
> corresponding change as they are no longer used on C libraries that have
> 64-bit time support.
>
> As we do for the other syscalls that have timespec arguments, we reuse
> the 'compat' syscall entry points to implement the traditional four
> interfaces, and only leave the new utimensat() as a native handler,
> so that the same code gets used on both 32-bit and 64-bit kernels
> on each syscall.
I wonder about the direction here: wouldn't it be easier to just
leave th existing syscall names as-is and introduce a new utimesat64
which uses the new timespec? We can then drop the old legacy utimesat
for new architectures added after the cutover.
^ permalink raw reply
* Re: [PATCH v2 05/17] asm-generic: Remove empty asm/unistd.h
From: Christoph Hellwig @ 2018-07-17 12:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: tglx, y2038, hch, linux-api, linux-arch, libc-alpha,
albert.aribaud, netdev, viro, peterz, dvhart, ebiederm, linux
In-Reply-To: <20180716161103.16239-6-arnd@arndb.de>
On Mon, Jul 16, 2018 at 06:10:51PM +0200, Arnd Bergmann wrote:
> Nothing is left in asm/unistd.h except for the redirect to
> uapi/asm/unistd.h, so removing the file simply leads to that one being
> used directly. The linux/export.h inclusion is a leftover from commit
> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
> and should not be used anyway.
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ 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