Re: [PATCH 5.10 098/138] zram: fix uninitialized ZRAM not releasing backing device

[Dominique Martinet <asmadeus@codewreck.org>]

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@tencent.com>
> 
> [ 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