Thanks Steve! On Sun, 2022-04-03 at 22:52 -0500, Steve French wrote: > Noticed this shift-out-of-bounds error in NFS, and also similar > messages logged in a few other drivers when running 5.18-rc1. It > seems to have regressed in the last ten days because I didn't see it > in the same setup when running an earlier version of the rc (about 10 > days ago). Any ideas? > > [Sun Apr 3 22:16:57 2022] UBSAN: shift-out-of-bounds in > lib/percpu-refcount.c:140:63 > [Sun Apr 3 22:16:57 2022] left shift of negative value - > 9223372036854775807 > [Sun Apr 3 22:16:57 2022] CPU: 7 PID: 10230 Comm: aio-free-ring-w Not > tainted 5.18.0-rc1 #1 > [Sun Apr 3 22:16:57 2022] Hardware name: Red Hat KVM, BIOS 0.5.1 > 01/01/2011 > [Sun Apr 3 22:16:57 2022] Call Trace: > [Sun Apr 3 22:16:57 2022] <TASK> > [Sun Apr 3 22:16:57 2022] dump_stack_lvl+0x55/0x6d > [Sun Apr 3 22:16:57 2022] ubsan_epilogue+0x5/0x40 > [Sun Apr 3 22:16:57 2022] > __ubsan_handle_shift_out_of_bounds+0xfa/0x140 > [Sun Apr 3 22:16:57 2022] ? lock_acquire+0x275/0x320 > [Sun Apr 3 22:16:57 2022] ? _raw_spin_unlock_irqrestore+0x40/0x60 > [Sun Apr 3 22:16:57 2022] ? percpu_ref_exit+0x87/0x90 > [Sun Apr 3 22:16:57 2022] percpu_ref_exit+0x87/0x90 > [Sun Apr 3 22:16:57 2022] ioctx_alloc+0x500/0x8f0 > [Sun Apr 3 22:16:57 2022] __x64_sys_io_setup+0x58/0x240 > [Sun Apr 3 22:16:57 2022] do_syscall_64+0x3a/0x80 > [Sun Apr 3 22:16:57 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae > [Sun Apr 3 22:16:57 2022] RIP: 0033:0x7f0c32c52d6d > [Sun Apr 3 22:16:57 2022] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 > 90 > f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c > 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d eb 80 0c 00 > f7 > d8 64 89 01 48 > [Sun Apr 3 22:16:57 2022] RSP: 002b:00007fffff3fedc8 EFLAGS: 00000202 > ORIG_RAX: 00000000000000ce > [Sun Apr 3 22:16:57 2022] RAX: ffffffffffffffda RBX: 0000000000002710 > RCX: 00007f0c32c52d6d > [Sun Apr 3 22:16:57 2022] RDX: 00007f0c32c52f47 RSI: 00007fffff3fee08 > RDI: 0000000000002710 > [Sun Apr 3 22:16:57 2022] RBP: 00007f0c32b586c0 R08: 0000000000000000 > R09: 00007fffff3fef08 > [Sun Apr 3 22:16:57 2022] R10: 0000000000000000 R11: 0000000000000202 > R12: 000000000000000c > [Sun Apr 3 22:16:57 2022] R13: 00007fffff3fee08 R14: 0000000000000000 > R15: 0000000000000000 > [Sun Apr 3 22:16:57 2022] </TASK> > [Sun Apr 3 22:16:57 2022] > ===================================================================== > =========== > [Sun Apr 3 22:16:57 2022] > ===================================================================== > =========== > [Sun Apr 3 22:16:57 2022] UBSAN: shift-out-of-bounds in > ./include/linux/nfs_fs.h:606:9 > [Sun Apr 3 22:16:57 2022] left shift of 1 by 63 places cannot be > represented in type 'long long int' Hmm... It looks like it is actually complaining about the definition of OFFSET_MAX in fs.h: #ifndef OFFSET_MAX #define INT_LIMIT(x) (~((x)1 << (sizeof(x)*8 - 1))) #define OFFSET_MAX INT_LIMIT(loff_t) #define OFFT_OFFSET_MAX INT_LIMIT(off_t) #endif Since loff_t is signed, I suspect it is unhappy that the shift by 63 overflows into a negative value. I don't know who wrote this code (it predates git) so punting to Al. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
