RE: [PATCH] qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union()
From: Justin He <hidden>
Date: 2021-07-20 09:30:47
Also in:
lkml
-----Original Message----- From: Jakub Kicinski <kuba@kernel.org> Sent: Tuesday, July 20, 2021 5:06 PM To: Justin He <redacted> Cc: Prabhakar Kushwaha <redacted>; David S. Miller [off-list ref]; Ariel Elior [off-list ref]; GR-everest-linux- l2@marvell.com; netdev@vger.kernel.org; Linux Kernel Mailing List <linux- kernel@vger.kernel.org>; nd [off-list ref]; Shai Malin [off-list ref]; Shai Malin [off-list ref]; Prabhakar Kushwaha [off-list ref] Subject: Re: [PATCH] qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union() On Tue, 20 Jul 2021 02:02:26 +0000, Justin He wrote:quoted
quoted
quoted
For instance: _qed_mcp_cmd_and_union() In while loop spin_lock_bh() qed_mcp_has_pending_cmd() (assume false), will break the loopI agree till here.quoted
if (cnt >= max_retries) { ... return -EAGAIN; <-- here returns -EAGAIN without invoking bhunlockquoted
quoted
quoted
}Because of break, cnt has not been increased. - cnt is still less than max_retries. - if (cnt >= max_retries) will not be *true*, leading tospin_unlock_bh().quoted
quoted
Hence pairing completed.Sorry, indeed. Let me check other possibilities. @David S. Miller Sorry for the inconvenience, could you please revert it in netdev tree?Please submit a revert patch with the conclusions from the discussion included in the commit message.
Okay,will do that Thanks for the reminder -- Cheers, Justin (Jia He)