Greg Kroah-Hartman wrote on Mon, Jan 06, 2025 at 04:17:02PM +0100: > 5.10-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Kairui Song <kasong@xxxxxxxxxxx> > > [ Upstream commit 74363ec674cb172d8856de25776c8f3103f05e2f ] > > Setting backing device is done before ZRAM initialization. If we set the > backing device, then remove the ZRAM module without initializing the > device, the backing device reference will be leaked and the device will be > hold forever. > > Fix this by always reset the ZRAM fully on rmmod or reset store. This causes a null pointer deref when reseting an uninitialized device: armadillo:/sys/block/zram0# echo 1 > reset [ 28.054565] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 28.063377] Mem abort info: [ 28.066182] ESR = 0x96000004 [ 28.069241] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.074557] SET = 0, FnV = 0 [ 28.077612] EA = 0, S1PTW = 0 [ 28.080755] Data abort info: [ 28.083633] ISV = 0, ISS = 0x00000004 [ 28.087473] CM = 0, WnR = 0 [ 28.090445] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000464f9000 [ 28.096888] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 28.103700] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 28.109965] Modules linked in: moal(E) cfg80211(E) mlan(E) [ 28.115458] CPU: 3 PID: 1900 Comm: sh Tainted: G E 5.10.233-rc1-gbbdff754b92c #1 [ 28.124153] Hardware name: Atmark-Techno Armadillo-IoT Gateway G4 Board (DT) [ 28.131201] pstate: a0000005 (NzCv daif -PAN -UAO -TCO BTYPE=--) [ 28.137211] pc : zcomp_cpu_dead+0x20/0x70 [ 28.141220] lr : cpuhp_invoke_callback+0xd4/0x204 [ 28.145920] sp : ffff800011a1bb10 [ 28.149231] x29: ffff800011a1bb10 x28: ffff000006562580 [ 28.154542] x27: 0000000000000000 x26: ffff80001148aab8 [ 28.159855] x25: ffff800010716210 x24: 0000000000000000 [ 28.165169] x23: ffff80001149cb70 x22: 0000000000000000 [ 28.170480] x21: 0000000000000010 x20: ffff80002e856000 [ 28.175791] x19: ffff80001149d790 x18: 0000000000000000 [ 28.181102] x17: 0000000000000000 x16: 0000000000000000 [ 28.186413] x15: 0000ffff9aa2f5b0 x14: 0000000000000000 [ 28.191726] x13: ffff800011a1bc96 x12: ffff800011a1bc70 [ 28.197036] x11: 0fffffffffffffff x10: 000000000000000a [ 28.202349] x9 : 0000000000000000 x8 : ffff000002a102b8 [ 28.207660] x7 : 0000000000000000 x6 : 0000000000000040 [ 28.212973] x5 : ffff00003fb4f6f0 x4 : 0000000000000000 [ 28.218285] x3 : 0000000000000010 x2 : ffff80001148aab8 [ 28.223596] x1 : 0000000000000010 x0 : 0000000000000000 [ 28.228907] Call trace: [ 28.231353] zcomp_cpu_dead+0x20/0x70 [ 28.235013] cpuhp_invoke_callback+0xd4/0x204 [ 28.239370] cpuhp_issue_call+0x168/0x1b4 [ 28.243378] __cpuhp_state_remove_instance+0x144/0x1f0 [ 28.248513] zcomp_destroy+0x24/0x44 [ 28.252086] zram_reset_device+0xfc/0x11c [ 28.256093] reset_store+0xa4/0x130 [ 28.259581] dev_attr_store+0x18/0x30 [ 28.263244] sysfs_kf_write+0x44/0x54 [ 28.266903] kernfs_fop_write_iter+0x134/0x1c4 [ 28.271346] new_sync_write+0xfc/0x1b0 [ 28.275093] vfs_write+0x240/0x2b0 [ 28.278492] ksys_write+0x74/0x110 [ 28.281891] __arm64_sys_write+0x1c/0x30 [ 28.285815] el0_svc_common.constprop.0+0x78/0x1c0 [ 28.290603] do_el0_svc+0x1c/0x30 [ 28.293916] el0_svc+0x10/0x20 [ 28.296968] el0_sync_handler+0x108/0x114 [ 28.300975] el0_sync+0x180/0x1c0 [ 28.304290] Code: 912ae042 a90153f3 f90013f5 f8605854 (f85f0033) [ 28.310382] ---[ end trace e91dc675f5f4a195 ]--- I'll look a bit more into it today and reply to this mail with anything I've found. (didn't test on master or anything else either) -- Dominique
