From: Omar Sandoval <osandov@osandov.com>
To: kernel test robot <xiaolong.ye@intel.com>
Cc: Omar Sandoval <osandov@fb.com>,
0day robot <fengguang.wu@intel.com>,
Anatoly Pugachev <matorola@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@01.org
Subject: Re: [lkp] [Btrfs] e5a7b11a5c: shift exponent 32 is too large for 32-bit type 'int'
Date: Thu, 14 Jul 2016 19:35:29 -0700 [thread overview]
Message-ID: <20160715023529.GA19948@vader> (raw)
In-Reply-To: <20160715015120.GB6978@yexl-desktop>
On Fri, Jul 15, 2016 at 09:51:20AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> https://github.com/0day-ci/linux Omar-Sandoval/Btrfs-fix-extent-buffer-bitmap-tests-on-big-endian-systems/20160713-074511
> commit e5a7b11a5caa8d42fe3fb4ff2d75b6811aeb8eb7 ("Btrfs: fix extent buffer bitmap tests on big-endian systems")
>
> in testcase: boot
>
> on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap with 1G memory
>
> caused below changes:
>
>
> +------------------------------------------------------------------+----------+------------+
> | | v4.7-rc7 | e5a7b11a5c |
> +------------------------------------------------------------------+----------+------------+
> | boot_successes | 0 | 0 |
> | boot_failures | 80 | 8 |
> | invoked_oom-killer:gfp_mask=0x | 59 | 2 |
> | Mem-Info | 59 | 2 |
> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 59 | 2 |
> | backtrace:btrfs_test_extent_io | 35 | 6 |
> | backtrace:init_btrfs_fs | 35 | 6 |
> | backtrace:kernel_init_freeable | 59 | 8 |
> | BUG:kernel_test_oversize | 11 | 4 |
> | backtrace:vfs_write | 24 | 2 |
> | backtrace:SyS_write | 24 | 2 |
> | backtrace:populate_rootfs | 24 | 2 |
> | kernel_BUG_at_mm/filemap.c | 1 | |
> | invalid_opcode:#[##]PREEMPT_SMP | 1 | |
> | RIP:unlock_page | 1 | |
> | Kernel_panic-not_syncing:Fatal_exception | 1 | |
> | backtrace:kswapd | 1 | |
> | BUG:kernel_boot_hang | 9 | |
> | BUG:kernel_torture_test_oversize | 0 | 2 |
> +------------------------------------------------------------------+----------+------------+
>
>
>
> [ 74.703186] UBSAN: Undefined behaviour in fs/btrfs/tests/extent-io-tests.c:367:4
> [ 74.703359] shift exponent 32 is too large for 32-bit type 'int'
> [ 74.703359] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7-00001-ge5a7b11 #1
> [ 74.703359] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
> [ 74.703359] 00000000ffffffff 0000000000000097 0000000000000001 0000000000000001
> [ 74.703359] 0000000000000000 0000000000000001 ffff880035143c48 ffffffff82046359
> [ 74.703359] ffffffff813e786b 000000007a4be528 000000007a4be500 0000000000000020
> [ 74.703359] Call Trace:
> [ 74.703359] [<ffffffff82046359>] dump_stack+0x290/0x3f0
> [ 74.703359] [<ffffffff813e786b>] ? printk+0x5d/0x65
> [ 74.703359] [<ffffffff8212cbd9>] ubsan_epilogue+0x12/0x3f
> [ 74.703359] [<ffffffff8212d61b>] __ubsan_handle_shift_out_of_bounds+0x19c/0x1d1
> [ 74.703359] [<ffffffff81ca5a42>] ? extent_buffer_bitmap_set+0x508/0x517
> [ 74.703359] [<ffffffff81e142e6>] __test_eb_bitmaps+0x5f1/0x7a7
> [ 74.703359] [<ffffffff81e142e6>] ? __test_eb_bitmaps+0x5f1/0x7a7
> [ 74.703359] [<ffffffff81e16479>] btrfs_test_extent_io+0x281/0x427
> [ 74.703359] [<ffffffff81d2b075>] ? cleanup_write_cache_enospc+0x88/0x88
> [ 74.703359] [<ffffffff8606d299>] init_btrfs_fs+0x926/0xd88
> [ 74.703359] [<ffffffff8606c973>] ? trace_event_define_fields_btrfs_space_reservation+0x32f/0x32f
> [ 74.703359] [<ffffffff81000884>] do_one_initcall+0x240/0x4ed
> [ 74.703359] [<ffffffff85fd107c>] kernel_init_freeable+0x3b7/0x628
> [ 74.703359] [<ffffffff83033b7f>] kernel_init+0x1c/0x49c
> [ 74.703359] [<ffffffff830600cf>] ret_from_fork+0x1f/0x40
> [ 74.703359] [<ffffffff83033b63>] ? rest_init+0x2aa/0x2aa
> [ 74.703359] ================================================================================
> [ 75.122581] BTRFS: selftest: Extent I/O tests finished
> [ 75.123550] BTRFS: selftest: Running btrfs_get_extent tests
Hm, that doesn't make much sense:
365 for (i = 0; i < len * BITS_PER_BYTE / 32; i++) {
366 x = (0x19660dULL * (u64)x + 0x3c6ef35fULL) & 0xffffffffU;
367 for (j = 0; j < 32; j++) {
368 if (x & (1U << j)) {
369 bitmap_set(bitmap, i * 32 + j, 1);
370 extent_buffer_bitmap_set(eb, 0, i * 32 + j, 1);
371 }
372 }
373 }
How are we shifting by 32? I'll try to reproduce this tomorrow, but I
wonder if it's a compiler/UBSAN bug.
--
Omar
prev parent reply other threads:[~2016-07-15 2:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 1:51 [lkp] [Btrfs] e5a7b11a5c: shift exponent 32 is too large for 32-bit type 'int' kernel test robot
2016-07-15 2:35 ` Omar Sandoval [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160715023529.GA19948@vader \
--to=osandov@osandov.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=matorola@gmail.com \
--cc=osandov@fb.com \
--cc=xiaolong.ye@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox