Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210711141430.896595-1-sxwjean@me.com> <07878d21-fa4d-fbf5-a292-b71c48847a5e@redhat.com>
In-Reply-To: <07878d21-fa4d-fbf5-a292-b71c48847a5e@redhat.com>
From:   Xiongwei Song <sxwjean@gmail.com>
Date:   Mon, 12 Jul 2021 16:18:36 +0800
Message-ID: <CAEVVKH_95TMa8RRChzG0ZzMdzx3gp7wWmbPnbUst3+mi8wFnBg@mail.gmail.com>
Subject: Re: [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context()
To:     Waiman Long <llong@redhat.com>
Cc:     Xiongwei Song <sxwjean@me.com>, peterz@infradead.org,
        mingo@redhat.com, will@kernel.org,
        Boqun Feng <boqun.feng@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 12, 2021 at 12:43 AM Waiman Long <llong@redhat.com> wrote:
>
> On 7/11/21 10:14 AM, Xiongwei Song wrote:
> > From: Xiongwei Song <sxwjean@gmail.com>
> >
> > We now always get a "Invalid wait context" warning with
> > CONFIG_PROVE_RAW_LOCK_NESTING=y, see the full warning below:
> >
> >       [    0.705900] =============================
> >       [    0.706002] [ BUG: Invalid wait context ]
> >       [    0.706180] 5.13.0+ #4 Not tainted
> >       [    0.706349] -----------------------------
>
> I believe the purpose of CONFIG_PROVE_RAW_LOCK_NESTING is experimental
> and it is turned off by default. Turning it on can cause problem as
> shown in your lockdep splat. Limiting it to just PREEMPT_RT will defeat
> its purpose to find potential spinlock nesting problem in non-PREEMPT_RT
> kernel.
As far as I know, a spinlock can nest another spinlock. In
non-PREEMPT_RT kernel
spin_lock and raw_spin_lock are same , so here acquiring a spin_lock in hardirq
context is acceptable, the warning is not needed. My knowledge on this
is not enough,
Will dig into this.

> The point is to fix the issue found,
Agree. I thought there was a spinlock usage issue, but by checking
deactivate_slab context,
looks like the spinlock usage is well. Maybe I'm missing something?

> not hiding it from appearing.
I'm not trying to hiding it, according to the code context, the fix is
reasonable from my point of
view. Let me check again.

Thank  you for the comments.

Regards,
Xiongwei
>
> Cheers,
> Longman
>