On Tue, Oct 10, 2023 at 6:51 PM Matthieu Baerts matttbe@kernel.org wrote:
Hi Naresh,
On 09/10/2023 22:43, Naresh Kamboju wrote:
On Mon, 9 Oct 2023 at 18:46, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.57 release. There are 162 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Oct 2023 13:00:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.57-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
The following kernel warnings were noticed several times on arm x15 devices running stable-rc 6.1.57-rc1 while running selftests: net: mptcp_connect.sh and netfilter: nft_fib.sh.
The possible unsafe locking scenario detected.
FYI, Stable-rc/ linux.6.1.y kernel running stable/ linux.6.5.y selftest in this case.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
kselftest: Running tests in net/mptcp
Thank you for having reported the issue and having added MPTCP ML in Cc!
Just to avoid confusions: the "WARNING" you shared when running 'mptcp_connect.sh' selftest appeared before creating the first MPTCP connection. It looks like there is no reference to MPTCP in the calltraces. Also, because you have the same issue with nft_fib.sh, I would say that this issue is not linked to MPTCP but rather to a recent modification in the IPv6 stack.
By chance, did you start a "git bisect" to identify the commit causing this issue?
I think stable teams missed to backport
commit c486640aa710ddd06c13a7f7162126e1552e8842 Author: Eric Dumazet edumazet@google.com Date: Mon Mar 13 20:17:32 2023 +0000
ipv6: remove one read_lock()/read_unlock() pair in rt6_check_neigh()
rt6_check_neigh() uses read_lock() to protect n->nud_state reading.
This seems overkill and causes false sharing.
Signed-off-by: Eric Dumazet edumazet@google.com Reviewed-by: David Ahern dsahern@kernel.org Reviewed-by: Martin KaFai Lau martin.lau@kernel.org Signed-off-by: Jakub Kicinski kuba@kernel.org