On Mon, Jun 21, 2021 at 04:30:11PM -0700, Luis Chamberlain wrote: > Provide a simple state machine to fix races with driver exit where we > remove the CPU multistate callbacks and re-initialization / creation of > new per CPU instances which should be managed by these callbacks. > > The zram driver makes use of cpu hotplug multistate support, whereby it > associates a struct zcomp per CPU. Each struct zcomp represents a > compression algorithm in charge of managing compression streams per CPU. > Although a compiled zram driver only supports a fixed set of compression > algorithms, each zram device gets a struct zcomp allocated per CPU. The > "multi" in CPU hotplug multstate refers to these per cpu struct zcomp > instances. Each of these will have the CPU hotplug callback called for > it on CPU plug / unplug. The kernel's CPU hotplug multistate keeps a > linked list of these different structures so that it will iterate over > them on CPU transitions. > > By default at driver initialization we will create just one zram device > (num_devices=1) and a zcomp structure then set for the now default > lzo-rle comrpession algorithm. At driver removal we first remove each > zram device, and so we destroy the associated struct zcomp per CPU. But > since we expose sysfs attributes to create new devices or reset / initialize > existing zram devices, we can easily end up re-initializing a struct zcomp > for a zram device before the exit routine of the module removes the cpu > hotplug callback. When this happens the kernel's CPU hotplug will detect > that at least one instance (struct zcomp for us) exists. This can happen > in the following situation: > > CPU 1 CPU 2 > > class_unregister(...); Now the sysfs files are removed and invalidated for all devices associated with that class. > idr_for_each(...); > zram_debugfs_destroy(); > disksize_store(...); How will this call into the kobject's store function if class_unregister() has already happened? > idr_destroy(...); > unregister_blkdev(...); Ah, it's a block device's store function you are worried about, not the class one? > cpuhp_remove_multi_state(...); > > The warning comes up on cpuhp_remove_multi_state() when it sees that the > state for CPUHP_ZCOMP_PREPARE does not have an empty instance linked list. > In this case, that a struct zcom still exists, the driver allowed its > creation per CPU even though we could have just freed them per CPU > though a call on another CPU, and we are then later trying to remove the > hotplug callback. > > Fix all this by providing a zram initialization boolean > protected the the shared in the driver zram_index_mutex, > which we can use to annotate when sysfs attributes are > safe to use or not -- once the driver is properly initialized. > When the driver is going down we also are sure to not let > userspace muck with attributes which may affect each per cpu > struct zcomp. > > This also fixes a series of possible memory leaks. The > crashes and memory leaks can easily be caused by issuing > the zram02.sh script from the LTP project [0] in a loop > in two separate windows: > > cd testcases/kernel/device-drivers/zram > while true; do PATH=$PATH:$PWD:$PWD/../../../lib/ ./zram02.sh; done > > You end up with a splat as follows: > > kernel: zram: Removed device: zram0 > kernel: zram: Added device: zram0 > kernel: zram0: detected capacity change from 0 to 209715200 > kernel: Adding 104857596k swap on /dev/zram0. Priority:-2 extents:1 across:104857596k SSFS > kernel: zram0: detected capacitky change from 209715200 to 0 > kernel: zram0: detected capacity change from 0 to 209715200 > kernel: ------------[ cut here ]------------ > kernel: Error: Removing state 63 which has instances left. > kernel: WARNING: CPU: 7 PID: 70457 at kernel/cpu.c:2069 __cpuhp_remove_state_cpuslocked+0xf9/0x100 > kernel: Modules linked in: zram(E-) zsmalloc(E) <etc> > kernel: CPU: 7 PID: 70457 Comm: rmmod Tainted: G E 5.12.0-rc1-next-20210304 #3 > kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 > kernel: RIP: 0010:__cpuhp_remove_state_cpuslocked+0xf9/0x100 > kernel: Code: <etc> > kernel: RSP: 0018:ffffa800c139be98 EFLAGS: 00010282 > kernel: RAX: 0000000000000000 RBX: ffffffff9083db58 RCX: ffff9609f7dd86d8 > kernel: RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9609f7dd86d0 > kernel: RBP: 0000000000000000i R08: 0000000000000000 R09: ffffa800c139bcb8 > kernel: R10: ffffa800c139bcb0 R11: ffffffff908bea40 R12: 000000000000003f > kernel: R13: 00000000000009d8 R14: 0000000000000000 R15: 0000000000000000 > kernel: FS: 00007f1b075a7540(0000) GS:ffff9609f7dc0000(0000) knlGS:0000000000000000 > kernel: CS: 0010 DS: 0000 ES 0000 CR0: 0000000080050033 > kernel: CR2: 00007f1b07610490 CR3: 00000001bd04e000 CR4: 0000000000350ee0 > kernel: Call Trace: > kernel: __cpuhp_remove_state+0x2e/0x80 > kernel: __do_sys_delete_module+0x190/0x2a0 > kernel: do_syscall_64+0x33/0x80 > kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae > > The "Error: Removing state 63 which has instances left" refers > to the zram per CPU struc zcomp instances left. > > [0] https://github.com/linux-test-project/ltp.git > > Acked-by: Minchan Kim <minchan@xxxxxxxxxx> > Signed-off-by: Luis Chamberlain <mcgrof@xxxxxxxxxx> > --- > drivers/block/zram/zram_drv.c | 63 ++++++++++++++++++++++++++++++----- > 1 file changed, 55 insertions(+), 8 deletions(-) > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index cf8deecc39ef..431b60cd85c1 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -44,6 +44,8 @@ static DEFINE_MUTEX(zram_index_mutex); > static int zram_major; > static const char *default_compressor = CONFIG_ZRAM_DEF_COMP; > > +bool zram_up; static? > + > /* Module params (documentation at end) */ > static unsigned int num_devices = 1; > /* > @@ -1704,6 +1706,7 @@ static void zram_reset_device(struct zram *zram) > comp = zram->comp; > disksize = zram->disksize; > zram->disksize = 0; > + zram->comp = NULL; Is this a new change? Other than these two things, seems reasonable, if not total overkill :) thanks, greg k-h