Bug 208173 - BUG: using smp_processor_id() in preemptible, caller is ext4_mb_new_blocks
Summary: BUG: using smp_processor_id() in preemptible, caller is ext4_mb_new_blocks
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-15 00:10 UTC by Tom Seewald
Modified: 2020-06-15 00:40 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.8.0-rc1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (243.03 KB, text/plain)
2020-06-15 00:10 UTC, Tom Seewald
Details
kernel config (166.70 KB, text/plain)
2020-06-15 00:11 UTC, Tom Seewald
Details

Description Tom Seewald 2020-06-15 00:10:53 UTC
Created attachment 289655 [details]
dmesg

Immediately after booting 5.8.0-rc1 and logging in, dmesg is filled with BUG backtraces like:

[   10.823091] BUG: using smp_processor_id() in preemptible [00000000] code: auditd/788
[   10.823095] caller is ext4_mb_new_blocks+0x285/0xd50
[   10.823096] CPU: 2 PID: 788 Comm: auditd Not tainted 5.8.0-rc1 #15
[   10.823097] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme4, BIOS P2.90 07/11/2013
[   10.823097] Call Trace:
[   10.823104]  dump_stack+0x57/0x70
[   10.823107]  check_preemption_disabled+0xab/0xc0
[   10.823109]  ext4_mb_new_blocks+0x285/0xd50
[   10.823112]  ? __kmalloc+0x1ac/0x280
[   10.823114]  ? ext4_find_extent+0x2a1/0x370
[   10.823116]  ? ext4_find_extent+0x163/0x370
[   10.823118]  ? release_pages+0x3b1/0x470
[   10.823120]  ext4_ext_map_blocks+0x84d/0xcc0
[   10.823122]  ext4_map_blocks+0xef/0x560
[   10.823124]  ? kmem_cache_alloc+0x181/0x220
[   10.823126]  ext4_writepages+0x856/0xe00
[   10.823130]  ? futex_wait+0x11d/0x210
[   10.823132]  ? do_writepages+0x41/0xd0
[   10.823134]  ? __ext4_mark_inode_dirty+0x250/0x250
[   10.823134]  do_writepages+0x41/0xd0
[   10.823137]  ? wbc_attach_and_unlock_inode+0xd6/0x140
[   10.823139]  __filemap_fdatawrite_range+0xcb/0x100
[   10.823141]  file_write_and_wait_range+0x5e/0xb0
[   10.823143]  ext4_sync_file+0x10c/0x3a0
[   10.823144]  do_fsync+0x38/0x70
[   10.823146]  __x64_sys_fsync+0x10/0x20
[   10.823147]  do_syscall_64+0x47/0x80
[   10.823150]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.823152] RIP: 0033:0x7fb904384f1b
[   10.823152] Code: Bad RIP value.
[   10.823153] RSP: 002b:00007fb903d4cd00 EFLAGS: 00000293 ORIG_RAX: 000000000000004a
[   10.823154] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb904384f1b
[   10.823155] RDX: 0000000000000001 RSI: 0000000000000081 RDI: 0000000000000005
[   10.823155] RBP: 000055c4f63e82c0 R08: 0000000000000000 R09: 00007fb903d4d700
[   10.823156] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffd56550cce
[   10.823156] R13: 00007ffd56550ccf R14: 00007ffd56550cd0 R15: 00007fb903d4d700
Comment 1 Tom Seewald 2020-06-15 00:11:37 UTC
Created attachment 289657 [details]
kernel config
Comment 2 Theodore Tso 2020-06-15 00:22:42 UTC
Fixed in [1]

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=811985365378df01386c3cfb7ff716e74ca376d5

Which unfortunately just missed getting included in 5.8-rc1.
Comment 3 Tom Seewald 2020-06-15 00:40:38 UTC
After looking around, syzkaller already found this bug [1], and a fix was already posted [2] but Linus didn't pull it before tagging the rc1 release.

I manually applied commit 811985365378df01386c3cfb7ff716e74ca376d5 ("ext4: mballoc: Use this_cpu_read instead of this_cpu_ptr") from https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git, and I can confirm that this fixes the problem. Hopefully this makes it in by rc2.

I'll close this report once Linus pulls the fix.

[1] https://syzkaller.appspot.com/bug?id=b7f459091a40a67a13f27d2281281ffd0ed8e5e1
[2] https://lore.kernel.org/lkml/20200614200034.GA3294624@mit.edu/T/

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