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
[email protected]