[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241023121945.GS402847@kernel.org>
Date: Wed, 23 Oct 2024 13:19:45 +0100
From: Simon Horman <horms@...nel.org>
To: "Matthieu Baerts (NGI0)" <matttbe@...nel.org>
Cc: mptcp@...ts.linux.dev, Mat Martineau <martineau@...nel.org>,
Geliang Tang <geliang@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Gregory Detal <gregory.detal@...il.com>,
Shuah Khan <shuah@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH net 1/3] mptcp: init: protect sched with rcu_read_lock
On Mon, Oct 21, 2024 at 12:25:26PM +0200, Matthieu Baerts (NGI0) wrote:
> Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT
> creates this splat when an MPTCP socket is created:
>
> =============================
> WARNING: suspicious RCU usage
> 6.12.0-rc2+ #11 Not tainted
> -----------------------------
> net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 2, debug_locks = 1
> no locks held by mptcp_connect/176.
>
> stack backtrace:
> CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Call Trace:
> <TASK>
> dump_stack_lvl (lib/dump_stack.c:123)
> lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
> mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7))
> mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1))
> ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28)
> inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386)
> ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1))
> __sock_create (net/socket.c:1576)
> __sys_socket (net/socket.c:1671)
> ? __pfx___sys_socket (net/socket.c:1712)
> ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1))
> __x64_sys_socket (net/socket.c:1728)
> do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1))
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
>
> That's because when the socket is initialised, rcu_read_lock() is not
> used despite the explicit comment written above the declaration of
> mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the
> warning.
>
> Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock")
> Cc: stable@...r.kernel.org
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/523
> Reviewed-by: Geliang Tang <geliang@...nel.org>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@...nel.org>
Reviewed-by: Simon Horman <horms@...nel.org>
Powered by blists - more mailing lists