[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210310212128.GR4332@42.do-not-panic.com>
Date: Wed, 10 Mar 2021 21:21:28 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: Minchan Kim <minchan@...nel.org>
Cc: ngupta@...are.org, sergey.senozhatsky.work@...il.com,
axboe@...nel.dk, mbenes@...e.com, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug
multistate
On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> If I understand correctly, bugs you found were related to module
> unloading race while the zram are still working.
No, that is a simplifcation of the issue. The issue consists of
two separate issues:
a) race against module unloading in light of incorrect racty use of
cpu hotplug multistate support
b) module unload race with sysfs attribute race on *any* driver which
has sysfs attributes which also shares the same lock as used during
module unload
It is important to realize that issue b) is actually a generic kernel
issue, it would be present on *any* driver which shares a lock used on
a sysfs attribute and module unload. I looked to implement a generic
solution on kernfs, however we don't yet have semantics to enable this
generically, and so for now each driver needs to deal with those races
on their own. That sysfs race is dealt with in the second patch.
The first patch only deals with the cpu hotplug races exposed at module
unloading.
Luis
Powered by blists - more mailing lists