From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3C58C43603 for ; Tue, 10 Dec 2019 21:15:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 81E35205C9 for ; Tue, 10 Dec 2019 21:15:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576012540; bh=NjRlAIeHy2SuCz+QP9LYcmS5+EbVEaQg+w2B50lwxqo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=V5d9PDshWy+fk6bHZMNHpghtpCoFKSAEEwLByeqkMGn0BK9yyLiSW3pQmH0sjdxpv 8fzjYbXNImaeqQu6ALW8JDfvcN3XxBZ/4ozpP4HgdI+PSK7BvVU4br3TJ0GSxZlHBC FKp2cfGNqBq7IEElLiJ6YUx/A7EH1iRLBS9NmR/Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728553AbfLJVPc (ORCPT ); Tue, 10 Dec 2019 16:15:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:40016 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728985AbfLJVNe (ORCPT ); Tue, 10 Dec 2019 16:13:34 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 636C521D7D; Tue, 10 Dec 2019 21:13:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576012413; bh=NjRlAIeHy2SuCz+QP9LYcmS5+EbVEaQg+w2B50lwxqo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w0WFqYaUnogY7mp3wL20P6sgLzJZ+lfUEvfDkkYIfscf+OFoYqnOJHTnIzhRMj/F/ Avxi6cur3P2cRDwbaH3u0lqzL4ee1XEgrPeji5VD+UX3wC0RhWka4KNpjOZbVBRyE7 BvCs3kkZKGY1OnGI+Kzh1NlrxMJ7JXAvTgZz3luE= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Robert Richter , John Garry , Borislav Petkov , huangming23@huawei.com, James Morse , linuxarm@huawei.com, linux-edac , Mauro Carvalho Chehab , tanxiaofei@huawei.com, Tony Luck , wanghuiqiang@huawei.com, Sasha Levin 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 Message-Id: <20191210210735.9077-291-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191210210735.9077-1-sashal@kernel.org> References: <20191210210735.9077-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Robert Richter [ 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 Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Tested-by: John Garry Cc: Cc: James Morse Cc: Cc: linux-edac Cc: Mauro Carvalho Chehab Cc: Cc: Tony Luck Cc: Link: https://lkml.kernel.org/r/20191121213628.21244-1-rrichter@marvell.com Signed-off-by: Sasha Levin --- 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