Re: [RFC RT v5.10] [rt] repair usage of raw_v6_hashinfo.lock in raw_seq_start()

[Luis Goncalves <lgoncalv@redhat.com>]

On Mon, Oct 11, 2021 at 1:33 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> 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
>