Bug 217174 - Plugging in usb external drive, mount and umount causes kernel Oops
Summary: Plugging in usb external drive, mount and umount causes kernel Oops
Status: RESOLVED CODE_FIX
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Default virtual assignee for Drivers/USB
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-10 18:49 UTC by Mike Cloaked
Modified: 2023-03-11 11:18 UTC (History)
1 user (show)

See Also:
Kernel Version: 6.2.3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Kernel Oops for usb external drive umount with kernel 6.2.3 (7.58 KB, text/plain)
2023-03-10 18:49 UTC, Mike Cloaked
Details

Description Mike Cloaked 2023-03-10 18:49:38 UTC
Created attachment 303922 [details]
Kernel Oops for usb external drive umount with kernel 6.2.3

The problem I am about to describe does not occur with the kernel 6.2.2, as the current arch kernel in the repos.

With kerne. 6.2.3 if I simply plug in a usb external drive, mount it and umount it, then the journal has a kernel Oops as in the attached journal segment.  This was tested on three different machines, running arch kernel 6.2.2 and 6.2.3 (from arch testing), and is fully reproducible.  In all cases running kernel 6.2.2 does not give this issue, and running kernel 6.2.3 causes the kernel Oops as soon as the external usb drive is umounted. 

Once the Oops had occurred then the machine will hang on shutdown and requires a hard reboot.
Comment 1 Gene 2023-03-10 19:12:24 UTC
I had same problem while doing some lvm changes - trace simmilar happens in 6.2.3


 BUG: kernel NULL pointer dereference, address: 0000000000000028
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0 
 Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 9 PID: 1118 Comm: lvcreate Tainted: G                T  6.2.3-1>
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z370 Ex>
 RIP: 0010:blk_throtl_update_limit_valid+0x1f/0x110
 Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 54 49 89 fc>
 RSP: 0018:ffffb5fd01b47bb8 EFLAGS: 00010046
 RAX: 0000000000000000 RBX: ffff9d09040d8000 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffffffff97b2f648 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9d090fce2c00
 R13: ffff9d090aedf060 R14: ffff9d090aedf1c8 R15: ffff9d090aedf0d8
 FS:  00007f3896fc7240(0000) GS:ffff9d109f040000(0000) knlGS:00000000>
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
 CR2: 0000000000000028 CR3: 0000000111ce4003 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  <TASK>
  throtl_pd_offline+0x40/0x70
  blkcg_deactivate_policy+0xab/0x140
  ? __pfx_dev_remove+0x10/0x10 [dm_mod]
  blk_throtl_exit+0x45/0x80
  disk_release+0x4a/0xf0
  device_release+0x34/0x90
  kobject_put+0x97/0x1d0
  cleanup_mapped_device+0xe0/0x170 [dm_mod]
  __dm_destroy+0x120/0x1e0 [dm_mod]
  dev_remove+0x11b/0x190 [dm_mod]
  ctl_ioctl+0x302/0x5b0 [dm_mod]
  dm_ctl_ioctl+0xe/0x20 [dm_mod]
  __x64_sys_ioctl+0x9c/0xe0
  do_syscall_64+0x5c/0x90
  entry_SYSCALL_64_after_hwframe+0x72/0xdc
 RIP: 0033:0x7f389745653f
 Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48>
 RSP: 002b:00007ffe5499e4f0 EFLAGS: 00000246 ORIG_RAX: 00000000000000>
 RAX: ffffffffffffffda RBX: 000055d198c3bec0 RCX: 00007f389745653f
 RDX: 000055d1994501b0 RSI: 00000000c138fd04 RDI: 0000000000000003
 RBP: 0000000000000006 R08: 000055d197547088 R09: 00007ffe5499e3a0
 R10: 0000000000000000 R11: 0000000000000246 R12: 000055d1974d10d6
 R13: 000055d199450260 R14: 000055d1974d10c7 R15: 000055d197545bbb
  </TASK>
 Modules linked in: dm_cache_smq dm_cache dm_persistent_data dm_bio_p>
  soundcore pcspkr intel_wmi_thunderbolt i2c_smbus mei sysimgblt inpu>
 CR2: 0000000000000028
 ---[ end trace 0000000000000000 ]---
 RIP: 0010:blk_throtl_update_limit_valid+0x1f/0x110
 Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 54 49 89 fc>
Comment 2 Gene 2023-03-10 19:16:41 UTC
Forgot to say in my case no USB - just 1 nvme and 7 sata drives.
Comment 3 Mike Cloaked 2023-03-10 20:43:55 UTC
I just tested 6.2.3 built reverting commit

bfe46d2efe46c5c952f982e2ca94fe2ec5e58e2a 

and the kernel Oops no longer occurs for me - so that resolves the issue I reported.

I have also tested a second build with two commits reverted as below, and this also
gives no Oops following usb umount.

So reverting both

bfe46d2efe46c5c952f982e2ca94fe2ec5e58e2a
57a425badc05c2e87e9f25713e5c3c0298e4202c

Has resolved the issue for me.
Comment 4 Mike Cloaked 2023-03-11 11:18:36 UTC
6.2.4 works fine with the reverted commits. Will close this bug.

Note You need to log in before you can comment on or make changes to this bug.