On Tue, Oct 10, 2023 at 6:51 PM Matthieu Baerts <matttbe@xxxxxxxxxx> wrote: > > Hi Naresh, > > On 09/10/2023 22:43, Naresh Kamboju wrote: > > On Mon, 9 Oct 2023 at 18:46, Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> 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.gz > >> 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@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> 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@xxxxxxxxxx> Reviewed-by: David Ahern <dsahern@xxxxxxxxxx> Reviewed-by: Martin KaFai Lau <martin.lau@xxxxxxxxxx> Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
