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:
> > 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.
