On Mon, Sep 30, 2019 at 10:46:39AM +0900, Tetsuo Handa wrote:
On 2019/09/30 9:28, Sasha Levin wrote:
On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote:
On 2019/09/29 22:54, Greg Kroah-Hartman wrote:
From: Waiman Long <long...@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().
Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in
__lock_downgrade()".
We had a revert patch shown below in the past.
We had a revert in the stable trees, but that revert was incorrect.
Take a look at commit 513e1073d52e55 upstream, it patches
__lock_set_class() (even though the subject line says
__lock_downgrade()). So this is not a backporting error as the revert
said it is, but is rather the intended location to be patched.
If this is actually wrong, then it should be addressed upstream first.
Hmm, upstream has two commits with same author, same date, same subject,
different hash, different content.
I couldn't find from
https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com
that
we want to patch both __lock_set_class() and __lock_downgrade(), but I found
that the tip-bot has patched
__lock_downgrade() on "2019-01-21 11:29" and __lock_set_class() on "2019-02-04
8:56".
Seems that we by error patched both functions, though patching both functions
should be harmless...
Right, there's a lot of confusion between the duplicate subject lines
and what this patch actually does. My point was that this is an upstream
issue rather than a stable issue, we're just aligning with upstream
here.
--
Thanks,
Sasha
