linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: Xiongwei Song <sxwjean@gmail.com>, 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>
Subject: Re: [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context()
Date: Mon, 12 Jul 2021 09:04:41 -0400	[thread overview]
Message-ID: <1c4c058b-3745-5586-4961-79d83fb5b049@redhat.com> (raw)
In-Reply-To: <CAEVVKH_95TMa8RRChzG0ZzMdzx3gp7wWmbPnbUst3+mi8wFnBg@mail.gmail.com>

On 7/12/21 4:18 AM, Xiongwei Song wrote:
> 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?

Yes, spinlock and raw spinlock are the same in non-RT kernel. They are 
only different in RT kernel. However, non-RT kernel is also more heavily 
tested than the RT kernel counterpart. The purpose of this config option 
is to expose spinlock nesting problem in more areas of the code. If you 
look at the config help text of PROVE_RAW_LOCK_NESTING:

         help
          Enable the raw_spinlock vs. spinlock nesting checks which ensure
          that the lock nesting rules for PREEMPT_RT enabled kernels are
          not violated.

          NOTE: There are known nesting problems. So if you enable this
          option expect lockdep splats until these problems have been fully
          addressed which is work in progress. This config switch allows to
          identify and analyze these problems. It will be removed and the
          check permanentely enabled once the main issues have been fixed.

          If unsure, select N.

So lockdep splat is expected. It will take time to address all the 
issues found.

Cheers,
Longman


  parent reply	other threads:[~2021-07-12 13:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-11 14:14 [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context() Xiongwei Song
2021-07-11 14:14 ` [RFC PATCH v1 2/3] locking/lockdep: Unify the return values " Xiongwei Song
2021-07-11 15:19   ` Waiman Long
2021-07-12  7:48     ` Xiongwei Song
2021-07-23  2:57   ` [locking/lockdep] e0a77a7a5a: WARNING:bad_unlock_balance_detected kernel test robot
2021-07-11 14:14 ` [PATCH v1 3/3] locking/lockdep,doc: Correct the max number of lock classes Xiongwei Song
2021-07-11 15:22   ` Waiman Long
2021-07-12  7:49     ` Xiongwei Song
2021-07-11 16:43 ` [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context() Waiman Long
2021-07-12  8:18   ` Xiongwei Song
2021-07-12  8:50     ` Boqun Feng
2021-07-12  9:21       ` Xiongwei Song
2021-07-12 13:04     ` Waiman Long [this message]
2021-07-12 15:03       ` Xiongwei Song
2021-07-13  2:29       ` Xiongwei Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c4c058b-3745-5586-4961-79d83fb5b049@redhat.com \
    --to=llong@redhat.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sxwjean@gmail.com \
    --cc=sxwjean@me.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).