On Thu, Sep 05, 2019 at 11:07:14AM +0800, Baolin Wang wrote:
From: Waiman Long longman@redhat.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@i-love.sakura.ne.jp Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long longman@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Paul E. McKenney paulmck@linux.vnet.ibm.com Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.c... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Baolin Wang baolin.wang@linaro.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).
thanks,
greg k-h