On Mon, Oct 11, 2021 at 1:33 PM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2021-10-04 22:53:08 [-0300], Luis Claudio R. Goncalves wrote: > > Avoid a possible circular locking dependency by taking the softirq_ctrl.lock > > before taking raw_v6_hashinfo.lock in raw_seq_start(), keeping locking order > > consistent. > > How do you reproduce this one? It does not trigger here. Maybe I'm doing > something wrong. The command > hping3 -C 3 -K 1 -c 1 $ip In order to reproduce that lockdep splat I am running the following tests from LTP lite: # Read every file in /proc. Not likely to crash, but does enough # to disturb the kernel. A good kernel latency killer too. # Was not sure why it should reside in runtest/crashme and won't get tested ever read_all_dev read_all -d /dev -p -q -r 3 read_all_proc read_all -d /proc -q -r 3 read_all_sys read_all -d /sys -q -r 3 One thing I noticed though is that I can't reproduce the problem when the tuned profile in use is *realtime*. I can reproduce the problem with the *throughput-performance* profile. Again, the use of tuned in the tests is mostly to reproduce the configuration in use at the moment. I can isolate the specific configuration that makes it possible to trigger the lockdep splat. > > triggers raw_icmp_error() from within the softirq processing. And > cat /proc/net/raw > > does raw_seq_start(). No BH here. Additionally during boot raw_hash_sk() > is invoked from non-BH context here but it is a write-lock so it has to > disable BH since there is at least one reader in BH. > > The ipv4 code looks close to the ipv6. The problem is that hping does > not support v6 :/ Maybe the ipv6 acquires a bh lock somewhere which > leads to this. > > Sebastian >
