From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Robert Richter <rrichter@marvell.com>,
John Garry <john.garry@huawei.com>, Borislav Petkov <bp@suse.de>,
huangming23@huawei.com, James Morse <james.morse@arm.com>,
linuxarm@huawei.com, linux-edac <linux-edac@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
tanxiaofei@huawei.com, Tony Luck <tony.luck@intel.com>,
wanghuiqiang@huawei.com, Sasha Levin <sashal@kernel.org>
Subject: [PATCH AUTOSEL 5.4 330/350] EDAC/ghes: Do not warn when incrementing refcount on 0
Date: Tue, 10 Dec 2019 16:07:15 -0500 [thread overview]
Message-ID: <20191210210735.9077-291-sashal@kernel.org> (raw)
In-Reply-To: <20191210210735.9077-1-sashal@kernel.org>
From: Robert Richter <rrichter@marvell.com>
[ Upstream commit 16214bd9e43a31683a7073664b000029bba00354 ]
The following warning from the refcount framework is seen during ghes
initialization:
EDAC MC0: Giving out device to module ghes_edac.c controller ghes_edac: DEV ghes (INTERRUPT)
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 36 PID: 1 at lib/refcount.c:156 refcount_inc_checked
[...]
Call trace:
refcount_inc_checked
ghes_edac_register
ghes_probe
...
It warns if the refcount is incremented from zero. This warning is
reasonable as a kernel object is typically created with a refcount of
one and freed once the refcount is zero. Afterwards the object would be
"used-after-free".
For GHES, the refcount is initialized with zero, and that is why this
message is seen when initializing the first instance. However, whenever
the refcount is zero, the device will be allocated and registered. Since
the ghes_reg_mutex protects the refcount and serializes allocation and
freeing of ghes devices, a use-after-free cannot happen here.
Instead of using refcount_inc() for the first instance, use
refcount_set(). This can be used here because the refcount is zero at
this point and can not change due to its protection by the mutex.
Fixes: 23f61b9fc5cc ("EDAC/ghes: Fix locking and memory barrier issues")
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: John Garry <john.garry@huawei.com>
Cc: <huangming23@huawei.com>
Cc: James Morse <james.morse@arm.com>
Cc: <linuxarm@huawei.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: <tanxiaofei@huawei.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <wanghuiqiang@huawei.com>
Link: https://lkml.kernel.org/r/20191121213628.21244-1-rrichter@marvell.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/edac/ghes_edac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 1858baa96211b..523dd56a798c9 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -572,8 +572,8 @@ int ghes_edac_register(struct ghes *ghes, struct device *dev)
ghes_pvt = pvt;
spin_unlock_irqrestore(&ghes_lock, flags);
- /* only increment on success */
- refcount_inc(&ghes_refcount);
+ /* only set on success */
+ refcount_set(&ghes_refcount, 1);
unlock:
mutex_unlock(&ghes_reg_mutex);
--
2.20.1
prev parent reply other threads:[~2019-12-10 21:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191210210735.9077-1-sashal@kernel.org>
2019-12-10 21:03 ` [PATCH AUTOSEL 5.4 124/350] x86/mce: Lower throttling MCE messages' priority to warning Sasha Levin
2019-12-10 21:04 ` [PATCH AUTOSEL 5.4 158/350] EDAC/amd64: Set grain per DIMM Sasha Levin
2019-12-10 21:05 ` [PATCH AUTOSEL 5.4 251/350] EDAC/ghes: Fix locking and memory barrier issues Sasha Levin
2019-12-10 21:06 ` [PATCH AUTOSEL 5.4 261/350] EDAC/ghes: Fix grain calculation Sasha Levin
2019-12-10 21:07 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191210210735.9077-291-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=bp@suse.de \
--cc=huangming23@huawei.com \
--cc=james.morse@arm.com \
--cc=john.garry@huawei.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mchehab@kernel.org \
--cc=rrichter@marvell.com \
--cc=stable@vger.kernel.org \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.com \
--cc=wanghuiqiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).