linux-kernel - Re: [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Jul 2021 23:03:10 +0800
From:   Xiongwei Song <sxwjean@...com>
To:     Waiman Long <llong@...hat.com>
Cc:     Xiongwei Song <sxwjean@...il.com>, peterz@...radead.org,
        mingo@...hat.com, will@...nel.org,
        Boqun Feng <boqun.feng@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of
 check_wait_context()


Regards,
Xiongwei




> On Jul 12, 2021, at 9:04 PM, Waiman Long <llong@...hat.com> wrote:
> 
> On 7/12/21 4:18 AM, Xiongwei Song wrote:
>> On Mon, Jul 12, 2021 at 12:43 AM Waiman Long <llong@...hat.com> wrote:
>>> On 7/11/21 10:14 AM, Xiongwei Song wrote:
>>>> From: Xiongwei Song <sxwjean@...il.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.
Thanks, :-).

Regards,
Xiongwei

> 
> Cheers,
> Longman
>