* Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 [not found] <c6e5eb81-680f-dd5c-8a81-62041a5ce50c@gmx.de> @ 2020-12-18 6:54 ` Randy Dunlap 2020-12-18 10:20 ` Toralf Förster 0 siblings, 1 reply; 4+ messages in thread From: Randy Dunlap @ 2020-12-18 6:54 UTC (permalink / raw) To: Toralf Förster, jgg; +Cc: Linux Kernel, Linux MM Hi, [adding linux-mm] On 12/16/20 1:54 AM, Toralf Förster wrote: > Hi, > > I got this recently at this hardened Gentoo Linux server: > > Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R) > Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux > > > Dec 15 23:31:51 mr-fox kernel: [ 1974.206972] > ================================================================================ > Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds > in ./include/linux/log2.h:57:13 > Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too > large for 64-bit type 'long unsigned int' > Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm: > cc1 Tainted: G T 5.10.1 #1 > Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK > COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018 > Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace: > Dec 15 23:31:51 mr-fox kernel: [ 1974.206993] dump_stack+0x57/0x6a > Dec 15 23:31:51 mr-fox kernel: [ 1974.206996] ubsan_epilogue+0x5/0x40 > Dec 15 23:31:51 mr-fox kernel: [ 1974.206999] > __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e > Dec 15 23:31:51 mr-fox kernel: [ 1974.207002] > ondemand_readahead.cold+0x16/0x21 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207007] > generic_file_buffered_read+0x452/0x890 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207011] new_sync_read+0x156/0x200 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207014] vfs_read+0xf8/0x190 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207016] ksys_read+0x65/0xe0 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207018] do_syscall_64+0x33/0x40 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207021] > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e > Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50 > 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 > 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f > 84 00 00 00 00 00 48 83 ec 28 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:00007fff2167e998 > EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffffffffffffffda RBX: > 0000000000000000 RCX: 00007f01b2df198e > Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX: 0000000000000000 RSI: > 00000000054dcc50 RDI: 0000000000000004 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 00000000054dcc50 R08: > 00000000054dcc50 R09: 0000000000000000 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10: 0000000000000000 R11: > 0000000000000246 R12: 00000000054dc3b0 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 0000000000008000 R14: > 00000000054c9800 R15: 0000000000000000 > Dec 15 23:31:51 mr-fox kernel: [ 1974.207037] > ================================================================================ > > > Known issue ? Not that I have heard about, but that's not conclusive. Looks to me like this is in mm/readahead.c: static unsigned long get_init_ra_size(unsigned long size, unsigned long max) { unsigned long newsize = roundup_pow_of_two(size); What filesystem? What workload? thanks. -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 2020-12-18 6:54 ` 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 Randy Dunlap @ 2020-12-18 10:20 ` Toralf Förster 2020-12-20 1:09 ` Randy Dunlap 0 siblings, 1 reply; 4+ messages in thread From: Toralf Förster @ 2020-12-18 10:20 UTC (permalink / raw) To: Randy Dunlap, jgg; +Cc: Linux Kernel, Linux MM On 12/18/20 7:54 AM, Randy Dunlap wrote: > Hi, > > [adding linux-mm] > > On 12/16/20 1:54 AM, Toralf Förster wrote: >> Hi, >> >> I got this recently at this hardened Gentoo Linux server: >> >> Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R) >> Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux >> >> >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206972] >> ================================================================================ >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds >> in ./include/linux/log2.h:57:13 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too >> large for 64-bit type 'long unsigned int' >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm: >> cc1 Tainted: G T 5.10.1 #1 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK >> COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace: >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206993] dump_stack+0x57/0x6a >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206996] ubsan_epilogue+0x5/0x40 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.206999] >> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207002] >> ondemand_readahead.cold+0x16/0x21 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207007] >> generic_file_buffered_read+0x452/0x890 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207011] new_sync_read+0x156/0x200 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207014] vfs_read+0xf8/0x190 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207016] ksys_read+0x65/0xe0 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207018] do_syscall_64+0x33/0x40 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207021] >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50 >> 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 >> 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f >> 84 00 00 00 00 00 48 83 ec 28 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:00007fff2167e998 >> EFLAGS: 00000246 ORIG_RAX: 0000000000000000 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffffffffffffffda RBX: >> 0000000000000000 RCX: 00007f01b2df198e >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX: 0000000000000000 RSI: >> 00000000054dcc50 RDI: 0000000000000004 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 00000000054dcc50 R08: >> 00000000054dcc50 R09: 0000000000000000 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10: 0000000000000000 R11: >> 0000000000000246 R12: 00000000054dc3b0 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 0000000000008000 R14: >> 00000000054c9800 R15: 0000000000000000 >> Dec 15 23:31:51 mr-fox kernel: [ 1974.207037] >> ================================================================================ >> >> >> Known issue ? > > Not that I have heard about, but that's not conclusive. > > Looks to me like this is in mm/readahead.c: > > static unsigned long get_init_ra_size(unsigned long size, unsigned long max) > { > unsigned long newsize = roundup_pow_of_two(size); > > > What filesystem? What workload? / is a 32 GB ext4 filesystem. Data are at 3 BTRFS filesystems, 1x 500 GB and 2x 1.6TB. 2 Tor relays run at 100% each and utilizes the 1 GBit/s by 50%-60% [1] 7 build bots are running over the Gentoo software repostory [2] 1 AFL bot fuzzies the Tor sources. Those 8 jobs are contained by a cgroup of 9 CPUs and 120 GB RAM [3], each job is contained further by an own sub cgroup of 1.5 CPU and 20 GB RAM [4] The host is monitored using sysstat, the load is about 11.8, CPU[all] at 80%, proc/s at 1800, cswchs/s at 20000 and so on. [1] https://metrics.torproject.org/rs.html#search/zwiebeltoralf [2] https://zwiebeltoralf.de/tinderbox.html [3] https://github.com/toralf/tinderbox/blob/master/bin/cgroup.sh [4] https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L15 -- Toralf ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 2020-12-18 10:20 ` Toralf Förster @ 2020-12-20 1:09 ` Randy Dunlap 2020-12-20 10:34 ` Toralf Förster 0 siblings, 1 reply; 4+ messages in thread From: Randy Dunlap @ 2020-12-20 1:09 UTC (permalink / raw) To: Toralf Förster, jgg; +Cc: Linux Kernel, Linux MM, Andrew Morton, axboe On 12/18/20 2:20 AM, Toralf Förster wrote: > On 12/18/20 7:54 AM, Randy Dunlap wrote: >> Hi, >> >> [adding linux-mm] >> >> On 12/16/20 1:54 AM, Toralf Förster wrote: >>> Hi, >>> >>> I got this recently at this hardened Gentoo Linux server: >>> >>> Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R) >>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux >>> >>> >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206972] >>> ================================================================================ >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds >>> in ./include/linux/log2.h:57:13 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too >>> large for 64-bit type 'long unsigned int' >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm: >>> cc1 Tainted: G T 5.10.1 #1 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK >>> COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace: >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206993] dump_stack+0x57/0x6a >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206996] ubsan_epilogue+0x5/0x40 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206999] >>> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207002] >>> ondemand_readahead.cold+0x16/0x21 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207007] >>> generic_file_buffered_read+0x452/0x890 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207011] new_sync_read+0x156/0x200 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207014] vfs_read+0xf8/0x190 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207016] ksys_read+0x65/0xe0 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207018] do_syscall_64+0x33/0x40 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207021] >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50 >>> 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 >>> 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f >>> 84 00 00 00 00 00 48 83 ec 28 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:00007fff2167e998 >>> EFLAGS: 00000246 ORIG_RAX: 0000000000000000 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffffffffffffffda RBX: >>> 0000000000000000 RCX: 00007f01b2df198e >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX: 0000000000000000 RSI: >>> 00000000054dcc50 RDI: 0000000000000004 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 00000000054dcc50 R08: >>> 00000000054dcc50 R09: 0000000000000000 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10: 0000000000000000 R11: >>> 0000000000000246 R12: 00000000054dc3b0 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 0000000000008000 R14: >>> 00000000054c9800 R15: 0000000000000000 >>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207037] >>> ================================================================================ >>> >>> >>> Known issue ? >> >> Not that I have heard about, but that's not conclusive. >> >> Looks to me like this is in mm/readahead.c: >> >> static unsigned long get_init_ra_size(unsigned long size, unsigned long max) >> { >> unsigned long newsize = roundup_pow_of_two(size); >> >> >> What filesystem? What workload? > > / is a 32 GB ext4 filesystem. > Data are at 3 BTRFS filesystems, 1x 500 GB and 2x 1.6TB. > > 2 Tor relays run at 100% each and utilizes the 1 GBit/s by 50%-60% [1] > > 7 build bots are running over the Gentoo software repostory [2] > 1 AFL bot fuzzies the Tor sources. > Those 8 jobs are contained by a cgroup of 9 CPUs and 120 GB RAM [3], > each job is contained further by an own sub cgroup of 1.5 CPU and 20 GB > RAM [4] > > The host is monitored using sysstat, the load is about 11.8, CPU[all] at > 80%, proc/s at 1800, cswchs/s at 20000 and so on. > > > [1] https://metrics.torproject.org/rs.html#search/zwiebeltoralf > [2] https://zwiebeltoralf.de/tinderbox.html > [3] https://github.com/toralf/tinderbox/blob/master/bin/cgroup.sh > [4] https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L15 > > -- Hi Toralf, Is this something that happens more than once? I think we would like to find out what is causing it. I see a couple of problems. (a) UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' <linux/log2.h>:57: is like so: 50 /** 51 * __roundup_pow_of_two() - round up to nearest power of two 52 * @n: value to round up 53 */ 54 static inline __attribute__((const)) 55 unsigned long __roundup_pow_of_two(unsigned long n) 56 { 57 return 1UL << fls_long(n - 1); 58 } It's OK/valid for fls_long() [fls64()] to return 64 for a bit position -- it just means the high-order bit in a 64-bit value. So this code should either always subtract 1 from fls_long() or do that if fls_long() == 64. (b) in mm/readahead.c:get_init_ra_size(): 305 /* 306 * Set the initial window size, round to next power of 2 and square 307 * for small size, x 4 for medium, and x 2 for large 308 * for 128k (32 page) max ra 309 * 1-8 page = 32k initial, > 8 page = 128k initial 310 */ 311 static unsigned long get_init_ra_size(unsigned long size, unsigned long max) 312 { 313 unsigned long newsize = roundup_pow_of_two(size); It looks like 'size' is either extremely large or it might be negative if it were a signed long instead of unsigned, so maybe it's 0x80000000_00000000 or 0xffffffff_ffffffff or something similar. I think that we should add a WARN_ON_ONCE() there to try to catch whatever it is. Is this something that you could test if I send some patches? Unless other people have some other ideas, that is... thanks. -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 2020-12-20 1:09 ` Randy Dunlap @ 2020-12-20 10:34 ` Toralf Förster 0 siblings, 0 replies; 4+ messages in thread From: Toralf Förster @ 2020-12-20 10:34 UTC (permalink / raw) To: Randy Dunlap, jgg; +Cc: Linux Kernel, Linux MM, Andrew Morton, axboe On 12/20/20 2:09 AM, Randy Dunlap wrote: > On 12/18/20 2:20 AM, Toralf Förster wrote: >> On 12/18/20 7:54 AM, Randy Dunlap wrote: >>> Hi, >>> >>> [adding linux-mm] >>> >>> On 12/16/20 1:54 AM, Toralf Förster wrote: >>>> Hi, >>>> >>>> I got this recently at this hardened Gentoo Linux server: >>>> >>>> Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R) >>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux >>>> >>>> >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206972] >>>> ================================================================================ >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds >>>> in ./include/linux/log2.h:57:13 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too >>>> large for 64-bit type 'long unsigned int' >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm: >>>> cc1 Tainted: G T 5.10.1 #1 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK >>>> COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace: >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206993] dump_stack+0x57/0x6a >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206996] ubsan_epilogue+0x5/0x40 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206999] >>>> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207002] >>>> ondemand_readahead.cold+0x16/0x21 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207007] >>>> generic_file_buffered_read+0x452/0x890 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207011] new_sync_read+0x156/0x200 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207014] vfs_read+0xf8/0x190 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207016] ksys_read+0x65/0xe0 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207018] do_syscall_64+0x33/0x40 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207021] >>>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50 >>>> 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 >>>> 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f >>>> 84 00 00 00 00 00 48 83 ec 28 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:00007fff2167e998 >>>> EFLAGS: 00000246 ORIG_RAX: 0000000000000000 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffffffffffffffda RBX: >>>> 0000000000000000 RCX: 00007f01b2df198e >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX: 0000000000000000 RSI: >>>> 00000000054dcc50 RDI: 0000000000000004 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 00000000054dcc50 R08: >>>> 00000000054dcc50 R09: 0000000000000000 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10: 0000000000000000 R11: >>>> 0000000000000246 R12: 00000000054dc3b0 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 0000000000008000 R14: >>>> 00000000054c9800 R15: 0000000000000000 >>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207037] >>>> ================================================================================ >>>> >>>> >>>> Known issue ? >>> >>> Not that I have heard about, but that's not conclusive. >>> >>> Looks to me like this is in mm/readahead.c: >>> >>> static unsigned long get_init_ra_size(unsigned long size, unsigned long max) >>> { >>> unsigned long newsize = roundup_pow_of_two(size); >>> >>> >>> What filesystem? What workload? >> >> / is a 32 GB ext4 filesystem. >> Data are at 3 BTRFS filesystems, 1x 500 GB and 2x 1.6TB. >> >> 2 Tor relays run at 100% each and utilizes the 1 GBit/s by 50%-60% [1] >> >> 7 build bots are running over the Gentoo software repostory [2] >> 1 AFL bot fuzzies the Tor sources. >> Those 8 jobs are contained by a cgroup of 9 CPUs and 120 GB RAM [3], >> each job is contained further by an own sub cgroup of 1.5 CPU and 20 GB >> RAM [4] >> >> The host is monitored using sysstat, the load is about 11.8, CPU[all] at >> 80%, proc/s at 1800, cswchs/s at 20000 and so on. >> >> >> [1] https://metrics.torproject.org/rs.html#search/zwiebeltoralf >> [2] https://zwiebeltoralf.de/tinderbox.html >> [3] https://github.com/toralf/tinderbox/blob/master/bin/cgroup.sh >> [4] https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L15 >> >> -- > > Hi Toralf, > > Is this something that happens more than once? Till now only once. > I think we would like to find out what is causing it. > I see a couple of problems. > > (a) > UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 > shift exponent 64 is too large for 64-bit type 'long unsigned int' > > <linux/log2.h>:57: is like so: > > 50 /** > 51 * __roundup_pow_of_two() - round up to nearest power of two > 52 * @n: value to round up > 53 */ > 54 static inline __attribute__((const)) > 55 unsigned long __roundup_pow_of_two(unsigned long n) > 56 { > 57 return 1UL << fls_long(n - 1); > 58 } > > It's OK/valid for fls_long() [fls64()] to return 64 for a bit > position -- it just means the high-order bit in a 64-bit value. > So this code should either always subtract 1 from fls_long() or > do that if fls_long() == 64. > > > (b) in mm/readahead.c:get_init_ra_size(): > > 305 /* > 306 * Set the initial window size, round to next power of 2 and square > 307 * for small size, x 4 for medium, and x 2 for large > 308 * for 128k (32 page) max ra > 309 * 1-8 page = 32k initial, > 8 page = 128k initial > 310 */ > 311 static unsigned long get_init_ra_size(unsigned long size, unsigned long max) > 312 { > 313 unsigned long newsize = roundup_pow_of_two(size); > > It looks like 'size' is either extremely large or it might be negative if > it were a signed long instead of unsigned, so maybe it's 0x80000000_00000000 > or 0xffffffff_ffffffff or something similar. I think that we should add a > WARN_ON_ONCE() there to try to catch whatever it is. > > > Is this something that you could test if I send some patches? Sure, no problem > Unless other people have some other ideas, that is... > > thanks. > -- Toralf ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-20 10:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <c6e5eb81-680f-dd5c-8a81-62041a5ce50c@gmx.de>
2020-12-18 6:54 ` 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1 Randy Dunlap
2020-12-18 10:20 ` Toralf Förster
2020-12-20 1:09 ` Randy Dunlap
2020-12-20 10:34 ` Toralf Förster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).