Messages in this thread | | | Date | Mon, 30 Sep 2019 07:35:57 -0400 | From | Sasha Levin <> | Subject | Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade() |
| |
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 <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(). >>> >>> 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-longman@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
| |