lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a3650ed-b456-a29d-20ae-16de384146ef@suse.de>
Date:   Tue, 2 Apr 2019 11:30:10 +0800
From:   Qu Wenruo <wqu@...e.de>
To:     Rong Chen <rong.a.chen@...el.com>, dsterba@...e.cz,
        Nikolay Borisov <nborisov@...e.com>, lkp@...org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Yoon Jungyeon <jungyeon@...ech.edu>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [LKP] [btrfs] 70d28b0e4f:
 BUG:kernel_reboot-without-warning_in_early-boot_stage,
 last_printk:Probing_EDD(edd=off_to_disable)...ok



On 2019/4/2 上午11:14, Rong Chen wrote:
> 
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800,  Chen, Rong A  wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
>>>> On 2019/4/1 下午10:02,  Chen, Rong A  wrote:
>>>>> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>>>>>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>>>>>> FYI, we noticed the following commit (built with gcc-7):
>>>>>>>
>>>>>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>>>>>> tree-checker: Verify dev item")
>>>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
>>>>>>> master
>>>>>>>
>>>>>>> in testcase: trinity
>>>>>>> with following parameters:
>>>>>>>
>>>>>>>       runtime: 300s
>>>>>>>
>>>>>>> test-description: Trinity is a linux system call fuzz tester.
>>>>>>> test-url: http://codemonkey.org.uk/projects/trinity/
>>>>>>>
>>>>>>>
>>>>>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
>>>>>>> -smp
>>>>>>> 2 -m 2G
>>>>>>>
>>>>>>> caused below changes (please refer to attached dmesg/kmsg for entire
>>>>>>> log/backtrace):
>>>>>>>
>>>>>>>
>>>>>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
>>>>>>>
>>>>>>>
>>>>>>> |
>>>>>>> | 36b9d2bc69 | 70d28b0e4f |
>>>>>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
>>>>>>>
>>>>>>>
>>>>>>> |
>>>>>>> boot_successes
>>>>>>> | 14         | 0          |
>>>>>>> |
>>>>>>> boot_failures
>>>>>>> | 2          | 14         |
>>>>>>> |
>>>>>>> IP-Config:Auto-configuration_of_network_failed
>>>>>>> | 2          |            |
>>>>>>> |
>>>>>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
>>>>>>>
>>>>>>> | 0          | 14         |
>>>>>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> early console in setup code
>>>>>>> Probing EDD (edd=off to disable)... ok
>>>>>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>>>>>> Probing EDD (edd=off to disable)... ok
>>>>>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
>>>>>>> Command line: ip=::::vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
>>>>>>> user=lkp
>>>>>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
>>>>>>>
>>>>>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
>>>>>>> branch=linux-devel/devel-hourly-2019032317
>>>>>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
>>>>>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
>>>>>>>
>>>>>>> max_uptime=1500
>>>>>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
>>>>>>>
>>>>>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
>>>>>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
>>>>>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>>>>>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
>>>>>>> systemd.log_level=err ignore_loglevel console=tty0
>>>>>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
>>>>>>> rcuperf.shutdown=0
>>>>>>>
>>>>>> Can this report be made useful by actually including output from
>>>>>> serial
>>>>>> console? For example possible bug-ons or whatnot? dmesg.xz just
>>>>>> contains
>>>>>> qemu's command line + some metadata about the test and :
>>>>>>
>>>>>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>>>>> Probing EDD (edd=off to disable)... ok"
>>>>>>
>>>>>> At least a stack trace would have been useful.
>>>>>>
>>>>>> <snip>
>>>>> Hi,
>>>>>
>>>>> We usually use the tool ("bin/lkp qemu -k <bzImage> job-script") to
>>>>> reproduce it.  It seems no stack trace in the result:
>>>> So there is no regression at that commit right?
>>>>
>>>> Just some false alert?
>>>
>>> Hi,
>>>
>>> I think there's a regression, it stopped in the early-boot stage .
>> Can you please provide any logs that would point at btrfs? If the module
>> is loaded or built-in started, there's a line about that. Besides that
>> it's preceded by messages from other subsystems' initialization.
> 
> 
> Hi,
> 
> CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
> I disabled them for the experiment, and the new kernel is bootable. I
> don't have more logs to prove it.
> 
> $ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
> CONFIG_BTRFS_FS=y
> # CONFIG_BTRFS_FS_POSIX_ACL is not set
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> CONFIG_BTRFS_FS_REF_VERIFY=y

That's strange, ref verify part is pretty far from the tree checker code.

Would you please try to compile btrfs as module and then insert the
module to get some valid kernel messages?

Thanks,
Qu

> 
> 
> Best Regards,
> Rong Chen
> 
> 
>> _______________________________________________
>> LKP mailing list
>> LKP@...ts.01.org
>> https://lists.01.org/mailman/listinfo/lkp

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ