linux-kernel - Re: [BACKPORT 4.14.y v3 1/3] locking/lockdep: Add debug_locks check in __lock

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] [day] [month] [year] [list]

Date:   Thu, 26 Sep 2019 10:04:35 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Waiman Long <longman@...hat.com>
Cc:     "# 3.4.x" <stable@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        Orson Zhai <orsonzhai@...il.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [BACKPORT 4.14.y v3 1/3] locking/lockdep: Add debug_locks check
 in __lock_downgrade()

On Wed, 25 Sep 2019 at 22:05, Waiman Long <longman@...hat.com> wrote:
>
> On 9/25/19 6:01 AM, Baolin Wang wrote:
> > From: Waiman Long <longman@...hat.com>
> >
> > [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf]
> >
> > Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
> > warning right after a previous lockdep warning. It is likely that the
> > previous warning turned off lock debugging causing the lockdep to have
> > inconsistency states leading to the lock downgrade warning.
> >
> > Fix that by add a check for debug_locks at the beginning of
> > __lock_downgrade().
> >
> > Reported-by: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
> > Reported-by: syzbot+53383ae265fb161ef488@...kaller.appspotmail.com
> > Signed-off-by: Waiman Long <longman@...hat.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> > Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Will Deacon <will.deacon@....com>
> > Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com
> > Signed-off-by: Ingo Molnar <mingo@...nel.org>
> > Signed-off-by: Baolin Wang <baolin.wang@...aro.org>
> > ---
> >  kernel/locking/lockdep.c |    3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 565005a..5c370c6 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth,
> >       unsigned int depth;
> >       int i;
> >
> > +     if (unlikely(!debug_locks))
> > +             return 0;
> > +
> >       depth = curr->lockdep_depth;
> >       /*
> >        * This function is about (re)setting the class of a held lock,
>
> Apparently, there are 2 such patches in the upstream kernel - commit
> 513e1073d52e55b8024b4f238a48de7587c64ccf and
> 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by
> the fact that there are 2 places in the code that can match the hunks.
> Anyway, this looks like it is applying to the wrong function. It should
> be applied to __lock_downgrade. Though it shouldn't harm if it is
> applied to the wrong function.

Ah, I noticed there are 2 commits with the same commit message, though
513e1073d52e55b8024b4f238a48de7587c64ccf patch did not change the
__lock_downgrade(), which is really confusing. This patch
(513e1073d52e55b8024b4f238a48de7587c64ccf) did the right thing, and
71492580571467fb7177aade19c18ce7486267f5 patch should be applied to
__lock_downgrade.

I'll backport commit 71492580571467fb7177aade19c18ce7486267f5 too in
future. Thanks.

-- 
Baolin Wang
Best Regards