On Wed, Mar 10, 2021 at 09:21:28PM +0000, Luis Chamberlain wrote:
On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
quoted
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
Could you add some pusedo code sequence to show the race cleary?
It would be great if it goes in the description, too since it's
more clear to show the problme.
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
Yub, that part I missed. Maybe, we need some wrapper to zram sysfs
to get try_module_get in the warapper funnction and then call sub
rountine only if it got the refcount.
zram_sysfs_wrapper(func, A, B)
if (!try_module_get(THIS_MODULE)
return -ENODEV;
ret = func(A,B);
module_put(THIS_MODULE);
return ret;
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.
It's unforunate. Let me Cc Greg who might have some ideas or
find zram mess on zram sysfs implementation.
The first patch only deals with the cpu hotplug races exposed at module
unloading.
True. Thanks for the clarification.