lkml.org 
[lkml]   [2022]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 5.19 0191/1157] hwmon: (sht15) Fix wrong assumptions in device remove callback
    On Sat, Aug 20, 2022 at 08:14:42PM +0200, Greg Kroah-Hartman wrote:
    > On Fri, Aug 19, 2022 at 09:35:01PM +0200, Uwe Kleine-König wrote:
    > > Hello Greg,
    > >
    > > On Tue, Aug 16, 2022 at 12:40:50PM +0200, Greg Kroah-Hartman wrote:
    > > > On Mon, Aug 15, 2022 at 11:49:11PM +0200, Uwe Kleine-König wrote:
    > > > > On Mon, Aug 15, 2022 at 07:52:27PM +0200, Greg Kroah-Hartman wrote:
    > > > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    > > > > >
    > > > > > [ Upstream commit 7d4edccc9bbfe1dcdff641343f7b0c6763fbe774 ]
    > > > > >
    > > > > > Taking a lock at the beginning of .remove() doesn't prevent new readers.
    > > > > > With the existing approach it can happen, that a read occurs just when
    > > > > > the lock was taken blocking the reader until the lock is released at the
    > > > > > end of the remove callback which then accessed *data that is already
    > > > > > freed then.
    > > > > >
    > > > > > To actually fix this problem the hwmon core needs some adaption. Until
    > > > > > this is implemented take the optimistic approach of assuming that all
    > > > > > readers are gone after hwmon_device_unregister() and
    > > > > > sysfs_remove_group() as most other drivers do. (And once the core
    > > > > > implements that, taking the lock would deadlock.)
    > > > > >
    > > > > > So drop the lock, move the reset to after device unregistration to keep
    > > > > > the device in a workable state until it's deregistered. Also add a error
    > > > > > message in case the reset fails and return 0 anyhow. (Returning an error
    > > > > > code, doesn't stop the platform device unregistration and only results
    > > > > > in a little helpful error message before the devm cleanup handlers are
    > > > > > called.)
    > > > > >
    > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    > > > > > Link: https://lore.kernel.org/r/20220725194344.150098-1-u.kleine-koenig@pengutronix.de
    > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    > > > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
    > > > >
    > > > > Does this mean my concerns I expressed in the mail with Message-Id:
    > > > > 20220814155638.idxnihylofsxqlql@pengutronix.de were not taken into
    > > > > consideration?
    > > >
    > > > I can't find that message-id on lore.kernel.org, do you have a link?
    > >
    > > Oh, I missed your request earlier. No I don't have a link, the mail was
    > > sent to Sasha Levin, Jean Delvare, Guenter Roeck and stable-commits as I
    > > just replied to the "note to let you know that I've just added the patch
    > > titled [...] to the 5.19-stable tree".
    >
    > Ok, I've dropped it now from all pending queues (5.10 and older), I can
    > also revert it from the newer ones if you want me to.

    Actually I don't care much. It touches a path that is not usually hit,
    because platform devices are not removed very often. So I expect even if
    the problem with this driver is a different one now, we won't get any
    regressions here.

    Best regards
    Uwe

    --
    Pengutronix e.K. | Uwe Kleine-König |
    Industrial Linux Solutions | https://www.pengutronix.de/ |
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2022-08-21 10:07    [W:4.063 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site