[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMz4kuJniq8gzCAGRiCZoLp5D+dH-CfnUCmmkxN6-e1c2xaPNQ@mail.gmail.com>
Date: Wed, 11 Sep 2019 11:39:30 +0800
From: Baolin Wang <baolin.wang@...aro.org>
To: Greg KH <greg@...ah.com>
Cc: "# 3.4.x" <stable@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, longman@...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 v2 2/6] locking/lockdep: Add debug_locks check
in __lock_downgrade()
On Tue, 10 Sep 2019 at 22:32, Greg KH <greg@...ah.com> wrote:
>
> On Thu, Sep 05, 2019 at 11:07:14AM +0800, 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(+)
>
> Why isn't this relevant for 4.19.y? I can't add a patch to 4.14.y and
> then have someone upgrade to 4.19.y and not have the same fix in there,
> that would be a regression.
>
> So can you redo this series also with a 4.19.y set at the same so we
> don't get out of sync? I've queued up your first patch already as that
> was in 4.19.y (and also needed in 4.9.y).
I understood, will do. Thanks.
--
Baolin Wang
Best Regards
Powered by blists - more mailing lists