Patch "EDAC/ghes: Do not warn when incrementing refcount on 0" has been added to the 5.3-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    EDAC/ghes: Do not warn when incrementing refcount on 0

to the 5.3-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     edac-ghes-do-not-warn-when-incrementing-refcount-on-.patch
and it can be found in the queue-5.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit a52af19555691d1d3c21d16758fe15585aa6ae9a
Author: Robert Richter <rrichter@xxxxxxxxxxx>
Date:   Thu Nov 21 21:36:57 2019 +0000

    EDAC/ghes: Do not warn when incrementing refcount on 0
    
    [ 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@xxxxxxxxxx>
    Signed-off-by: Robert Richter <rrichter@xxxxxxxxxxx>
    Signed-off-by: Borislav Petkov <bp@xxxxxxx>
    Tested-by: John Garry <john.garry@xxxxxxxxxx>
    Cc: <huangming23@xxxxxxxxxx>
    Cc: James Morse <james.morse@xxxxxxx>
    Cc: <linuxarm@xxxxxxxxxx>
    Cc: linux-edac <linux-edac@xxxxxxxxxxxxxxx>
    Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
    Cc: <tanxiaofei@xxxxxxxxxx>
    Cc: Tony Luck <tony.luck@xxxxxxxxx>
    Cc: <wanghuiqiang@xxxxxxxxxx>
    Link: https://lkml.kernel.org/r/20191121213628.21244-1-rrichter@xxxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 1163c382d4a55..f9c17654045a5 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -566,8 +566,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);



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux