Re: [LKP] [rcu] kernel BUG at include/linux/pagemap.h:149!
by Frederic Weisbecker
On Fri, Sep 11, 2015 at 10:19:47AM +0800, Boqun Feng wrote:
> Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
> readers
>
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
>
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively.
>
> For debug purposes, preempt_disable() and preempt_enable() are still
> kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
> inside atomic sections still work in non-preemptible kernels.
>
> Signed-off-by: Boqun Feng <boqun.feng(a)gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> ---
> include/linux/rcupdate.h | 6 ++++--
> include/linux/rcutiny.h | 1 +
> kernel/rcu/tree.c | 9 +++++++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d63bb77..6c3cece 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,12 +297,14 @@ void synchronize_rcu(void);
>
> static inline void __rcu_read_lock(void)
> {
> - preempt_disable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_disable();
preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
So perhaps we can get rid of the IS_ENABLED() check?
1 year, 1 month
Extending the 0-day system with syzkaller?
by David Drysdale
Hi Fengguang / LKP-folk,
Quick question -- how easy is it to add extra builds/tests/checks to
your marvellous 0-day kbuild system?
The reason I ask is that I've recently been exploring syzkaller [1],
which is a system call fuzzer written by some of my colleagues here at
Google (cc'ed). Although it's fairly new, it has uncovered a bunch of
kernel bugs already [2] so I wondered if it might be a good candidate
for inclusion in the 0-day checks at some point.
(As an aside, I'm in the process of writing an article about syzkaller
for LWN, which might also expose it to more folk.)
What do you think?
Thanks,
David
[1] https://github.com/google/syzkaller
[2] https://github.com/google/syzkaller/wiki/Found-Bugs
4 years, 1 month
Adding Xen to the kbuild bot?
by Andy Lutomirski
Hi all-
Would it make sense to add some basic Xen PV testing to the kbuild bot?
qemu can boot Xen like this:
qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
Linux has never been been able to do virtio under Xen, which will
screw up your scripts, but I'm cautiously optimistic that virtio will
work as expected on a Xen guest starting with Linux 4.6. If you want
to play around, it should work in this tree:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio...
I'm hoping to get that queued up for real in the next couple of days.
--Andy
4 years, 3 months
[lkp] [kbuild] 3edd9bd918: ### dt-test ### FAIL of_unittest_parse_phandle_with_args():300 of_count_phandle_with_args() returned -22, expected 7
by kernel test robot
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git topic/renesas-overlays
commit 3edd9bd9184acaac993d58b8177e176ea073c4a5 ("kbuild: Enable DT symbols when CONFIG_OF_OVERLAY is used")
As below, the log "### dt-test ### FAIL of_unittest_parse_phandle_with_args():300 of_count_phandle_with_args() returned -22, expected 7" showed with your commit.
[ 5.690908] Loading compiled-in X.509 certificates
[ 5.691622] page_owner is disabled
[ 5.693067] cryptomgr_probe (153) used greatest stack depth: 13960 bytes left
[ 5.693955] Key type trusted registered
[ 5.694911] Key type encrypted registered
[ 5.700168] device-tree: Duplicate name in testcase-data, renamed to "duplicate-name#1"
[ 5.708499] ### dt-test ### start of unittest - you will see error messages
[ 5.709689] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 5.710491] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():300 of_count_phandle_with_args() returned -22, expected 7
[ 5.711882] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 0 - data error on node /testcase-data/phandle-tests/provider2 rc=0
[ 5.713345] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 1 - data error on node /testcase-data/phandle-tests/provider1 rc=0
[ 5.714764] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 3 - data error on node /testcase-data/phandle-tests/provider0 rc=0
[ 5.716283] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 4 - data error on node /testcase-data/phandle-tests/provider3 rc=0
[ 5.717772] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 5.718578] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 6 - data error on node /testcase-data/phandle-tests/provider0 rc=-22
[ 5.720108] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 5.720963] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():354 index 7 - data error on node /testcase-data/phandle-tests/provider0 rc=-22
[ 5.722424] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider2
[ 5.723742] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider2
[ 5.725054] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 5.725816] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 5.726585] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():384 expected:-22 got:-2
[ 5.727594] ### dt-test ### FAIL of_unittest_parse_phandle_with_args():387 expected:-22 got:2
[ 5.728970]
FYI, raw QEMU command line is:
qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel /pkg/linux/x86_64-randconfig-s2-03292311/gcc-5/3edd9bd9184acaac993d58b8177e176ea073c4a5/vmlinuz-4.6.0-rc1-00030-g3edd9bd -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-intel12-yocto-x86_64-9/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s2-03292311-3edd9bd9184acaac993d58b8177e176ea073c4a5-20160330-40309-1w14x1w-0.yaml ARCH=x86_64 kconfig=x86_64-randconfig-s2-03292311 branch=linux-devel/devel-spot-201603292222 commit=3edd9bd9184acaac993d58b8177e176ea073c4a5 BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s2-03292311/gcc-5/3edd9bd9184acaac993d58b8177e176ea073c4a5/vmlinuz-4.6.0-rc1-00030-g3edd9bd max_uptime=600 RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-s2-03292311/gcc-5/3edd9bd9184acaac993d58b8177e176ea073c4a5/0 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw ip=::::vm-intel12-yocto-x86_64-9::dhcp drbd.minor_count=8' -initrd /fs/KVM/initrd-vm-intel12-yocto-x86_64-9 -m 320 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc base=localtime -drive file=/fs/KVM/disk0-vm-intel12-yocto-x86_64-9,media=disk,if=virtio -drive file=/fs/KVM/disk1-vm-intel12-yocto-x86_64-9,media=disk,if=virtio -pidfile /dev/shm/kboot/pid-vm-intel12-yocto-x86_64-9 -serial file:/dev/shm/kboot/serial-vm-intel12-yocto-x86_64-9 -daemonize -display none -monitor null
Thanks,
Xiaolong Ye
4 years, 3 months
[lkp] [drm/i915] 099b7960d3: WARNING: CPU: 4 PID: 664 at drivers/gpu/drm/i915/intel_uncore.c:548 assert_forcewakes_inactive+0x84/0x90 [i915]()
by kernel test robot
FYI, we noticed the below changes on
https://github.com/0day-ci/linux Chris-Wilson/drm-i915-Only-arm-the-forcewake-release-timer-on-the-final-put/20160324-215801
commit 099b7960d3785a64ff959e79fe75a510a09a6302 ("drm/i915: Only arm the forcewake release timer on the final put")
As below, the log "WARNING: CPU: 4 PID: 664 at drivers/gpu/drm/i915/intel_uncore.c:548 assert_forcewakes_inactive+0x84/0x90 [i915]()" showed with your commit.
<5>[ 30.841183] sd 0:0:0:0: [sda] Stopping disk
<6>[ 30.844768] e1000e: EEE TX LPI TIMER: 00000011
<4>[ 30.846301] ------------[ cut here ]------------
<4>[ 30.846329] WARNING: CPU: 4 PID: 664 at drivers/gpu/drm/i915/intel_uncore.c:548 assert_forcewakes_inactive+0x84/0x90 [i915]()
<4>[ 30.846330] WARN_ON(domain->wake_count)
<4>[ 30.846346] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver sg sd_mod snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel firewire_ohci aesni_intel lrw gf128mul glue_helper snd_hda_intel ablk_helper cryptd serio_raw pcspkr ppdev ahci i915 firewire_core snd_hda_codec libahci crc_itu_t snd_hda_core snd_hwdep snd_pcm libata snd_timer snd video shpchp soundcore drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm parport_pc parport nuvoton_cir rc_core
<4>[ 30.846348] CPU: 4 PID: 664 Comm: kworker/u16:20 Not tainted 4.5.0-rc7-01401-g099b796 #1
<4>[ 30.846348] Hardware name: /DH67GD, BIOS BLH6710H.86A.0132.2011.1007.1505 10/07/2011
<4>[ 30.846352] Workqueue: events_unbound async_run_entry_fn
<4>[ 30.846353] 0000000000000000 ffff8800bce77ba0 ffffffff8142612a ffff8800bce77be8
<4>[ 30.846354] ffffffffa0369570 ffff8800bce77bd8 ffffffff81079fe6 ffff88021d2900e0
<4>[ 30.846355] 0000000000000000 ffff88021d290000 000077fde2d70078 ffff88021d290000
<4>[ 30.846356] Call Trace:
<4>[ 30.846360] [<ffffffff8142612a>] dump_stack+0x63/0x89
<4>[ 30.846363] [<ffffffff81079fe6>] warn_slowpath_common+0x86/0xc0
<4>[ 30.846364] [<ffffffff8107a06c>] warn_slowpath_fmt+0x4c/0x50
<4>[ 30.846377] [<ffffffffa02e01c4>] assert_forcewakes_inactive+0x84/0x90 [i915]
<4>[ 30.846389] [<ffffffffa02e0404>] intel_uncore_forcewake_reset+0x234/0x330 [i915]
<4>[ 30.846399] [<ffffffffa0281d9c>] i915_drm_suspend+0x12c/0x1b0 [i915]
<4>[ 30.846408] [<ffffffffa0281e4f>] i915_pm_suspend+0x2f/0x50 [i915]
<4>[ 30.846410] [<ffffffff8146f0c6>] pci_pm_suspend+0x76/0x140
<4>[ 30.846411] [<ffffffff8146f050>] ? pci_pm_freeze+0xe0/0xe0
<4>[ 30.846413] [<ffffffff8158202c>] dpm_run_callback+0x4c/0x150
<4>[ 30.846414] [<ffffffff81582b64>] __device_suspend+0xf4/0x300
<4>[ 30.846414] [<ffffffff81582d8f>] async_suspend+0x1f/0xa0
<4>[ 30.846416] [<ffffffff8109b19a>] async_run_entry_fn+0x4a/0x140
<4>[ 30.846417] [<ffffffff81092365>] process_one_work+0x155/0x440
<4>[ 30.846419] [<ffffffff81092fae>] worker_thread+0x4e/0x4c0
<4>[ 30.846420] [<ffffffff81092f60>] ? rescuer_thread+0x350/0x350
<4>[ 30.846421] [<ffffffff81098554>] kthread+0xd4/0xf0
<4>[ 30.846422] [<ffffffff81098480>] ? kthread_park+0x60/0x60
<4>[ 30.846424] [<ffffffff818e5e3f>] ret_from_fork+0x3f/0x70
<4>[ 30.846425] [<ffffffff81098480>] ? kthread_park+0x60/0x60
<4>[ 30.846426] ---[ end trace a8ed49e006bcbdac ]---
<6>[ 31.054012] PM: suspend of devices complete after 212.947 msecs
To reproduce:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong Ye
4 years, 3 months
[lkp] [selinux] 759b31c1d4: unixbench.score -9.7% regression
by kernel test robot
FYI, we noticed that unixbench.score -9.7% regression on
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 759b31c1d4295a1dab34b4669ee838fb3131cd91 ("selinux: simply inode label states to INVALID and INITIALIZED")
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_task/rootfs/tbox_group/test/testcase:
gcc-4.9/performance/x86_64-rhel/1/debian-x86_64-2015-02-07.cgz/ivb42/pipe/unixbench
commit:
48c2353e841141683e13771ecd6684350004ccac
759b31c1d4295a1dab34b4669ee838fb3131cd91
48c2353e84114168 759b31c1d4295a1dab34b4669e
---------------- --------------------------
%stddev %change %stddev
\ | \
1972 ± 0% -9.7% 1781 ± 0% unixbench.score
16298 ± 5% -12.4% 14272 ± 5% cpuidle.C1-IVT.usage
10890 ± 19% +84.8% 20129 ± 28% cpuidle.POLL.usage
2394 ±153% +93.8% 4641 ± 90% numa-meminfo.node1.Inactive(anon)
2545 ±146% +89.6% 4827 ± 86% numa-meminfo.node1.Shmem
598.25 ±153% +93.9% 1160 ± 90% numa-vmstat.node1.nr_inactive_anon
636.00 ±146% +89.7% 1206 ± 86% numa-vmstat.node1.nr_shmem
19716 ± 8% -17.5% 16267 ± 12% sched_debug.cfs_rq:/.min_vruntime.stddev
19716 ± 8% -17.5% 16267 ± 12% sched_debug.cfs_rq:/.spread0.stddev
lkp-wsx02: Westmere-EX
Memory: 128G
unixbench.score
2000 *+**-*--*-*-----------------*-**-*-**-**-*-**-*-**-------------------+
| * **.**. + : *.*.**.**. |
| *.**.*.** : : *.**.*
1950 ++ *.* |
| |
| |
1900 ++ |
| |
1850 ++ |
| |
| |
1800 ++ O |
| OO OO O O O OO O OO O |
O OO O OO O |
1750 ++-------------------------------------------------------------------+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Xiaolong Ye
4 years, 3 months
Re: [LKP] [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
by Luis R. Rodriguez
On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani <toshi.kani(a)hpe.com> wrote:
> On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote:
>> On 03/29/2016 10:19 AM, Toshi Kani wrote:
>> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
>> >
>> > > > I'd appreciate if someone can test this patch-set on Xen to verify
>> > > > that there is no change in "x86/PAT: Configuration [0-7] .."
>> > > > message in dmesg.
>> > > So I don't have a Xen setup, but hopefully such testing will happen
>> > > once these changes show up in linux-next, tomorrow or so.
>> > I will address if any issue is found in testing.
>>
>> I ran a subset of out nightly test. Nobody died.
>>
>> So this all looks good. (It actually may have also fixed another bug
>> that was reported recently by Olaf, copied here)
>
> Cool! Thanks Boris!
Hoping Boris or someone on the Xen front would test this prior to
merging helps but it also slows us down, a while ago we discussed the
possibility of getting Linux Xen guests automatically tested as part
of 0-day, this way then when a developer (in this case Toshi) pushes
to his own tree, he'd be able to just sit and wait for the results,
without having to hope Boris or someone goes out and tests.
Its a major undertaking to get Linux Xen guests boot strapped into
0-day, however such prospects were raised a while ago and it seems we
may be able to get there. Just wanted to send a reminder about this
possibility, and highlight this patch set as an ideal candidate where
a proactive test could have helped as well. I proactively caught the
original Xen issue, but git logs shows we are not doing so great in
this area, so any help on the Xen side as well to help with 0-day
integration would be appreciated.
I'll follow up on another thread on that.
Luis
4 years, 3 months
Re: [LKP] Xen test suites - 0 day bot testing
by Luis R. Rodriguez
On Thu, Jan 21, 2016 at 11:17 AM, Luis R. Rodriguez
<mcgrof(a)do-not-panic.com> wrote:
> On Tue, Aug 25, 2015 at 1:47 PM, Fengguang Wu <fengguang.wu(a)intel.com> wrote:
>> On Tue, Aug 25, 2015 at 04:37:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Aug 26, 2015 at 04:29:10AM +0800, Fengguang Wu wrote:
>>> > Hi Vitaly,
>>> >
>>> > On Tue, Aug 25, 2015 at 02:11:57AM -0700, Vitaly Kuznetsov wrote:
>>> > > "Luis R. Rodriguez" <mcgrof(a)do-not-panic.com> writes:
>>> > >
>>> > > >> Robert Hu is from Intel VT QA team. I synced with him and it looks
>>> > > >> possible for him to bootstrap Xen from PXE, which is how 0day
>>> > > >> bootstraps Linux kernel. We rely mainly on kexec for kernel testing,
>>> > > >> not sure if that's possible for Xen.
>>> > > >
>>> > > > Kexec support requires some more work, the status of which Vitaly and
>>> > > > Olaf may be able to provide best.
>>> > > >
>>> > >
>>> > > (not sure which kexec was meant here: for Xen hypervisor itself, for
>>> > > hardware domain (aka Dom0) or for guest domains. In case guest kexec is
>>> > > required read the below comment:)
>>> >
>>> > It is kexec support for the test target, eg. Xen hypervisor if we are
>>> > going to test/bisect it and switch among its different git commits from
>>> > time to time.
>>>
>>> It should work. Make sure you have the latest version of kexec and you
>>> build it against the version of Xen you are booting.
>>
>> That'd be great! Thanks for the info!
>
> Fengguang, curious if there was some effort in this area.
>
> Also since we have tons of test suites out there in the wild a while
> ago I had asked help by LF admins for a wiki we could use to
> centralize documentation. Projects might have their own wiki already /
> project home page, but we didn't have anything centric, we also didn't
> have a place where any test work could just create their own page
> should they want to avoid that and instead use an existing wiki. To
> help with this we now have this:
>
> https://bottest.wiki.kernel.org/
>
> If your test work has no public page it can use that. I've tried to
> document things I know of already. My understanding is zero day bot
> has no central documentation wiki, perhaps we can use that as its home
> ?
I've updated the wiki to point to the new 0-day home page but still
curious about ongoing efforts over Xen integration. I realize the task
at hand is huge undertaking -- but just curious if its on the roadmap.
Thanks so much for all your awesome work folks!
Luis
4 years, 3 months
[mm, vmscan] 970df71e43: BUG: unable to handle kernel paging request at 0000000000016f29
by kernel test robot
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux mm-vmscan-node-lru-v3r10
commit 970df71e432f080bee5548dd6ee6606943ef3236
Author: Mel Gorman <mgorman(a)techsingularity.net>
AuthorDate: Thu Apr 16 17:30:55 2015 +0100
Commit: Mel Gorman <mgorman(a)techsingularity.net>
CommitDate: Wed Mar 30 11:33:22 2016 +0100
mm, vmscan: Move LRU lists to node
This moves the LRU lists from the zone to the node and all related data
such as counters, tracing, congestion tracking and writeback tracking.
This is mostly a mechanical patch but note that it introduces a number
of anomalies. For example, the scans are per-zone but using per-node
counters. We also mark a node as congested when a zone is congested. This
causes weird problems that are fixed later but is easier to review.
Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
+------------------------------------------+------------+------------+------------+
| | 7db93e3a25 | 970df71e43 | 8405105053 |
+------------------------------------------+------------+------------+------------+
| boot_successes | 190 | 16 | 0 |
| boot_failures | 0 | 52 | 13 |
| BUG:unable_to_handle_kernel | 0 | 52 | 13 |
| Oops | 0 | 52 | 13 |
| RIP:cpu_vm_stats_fold | 0 | 52 | 13 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 52 | 13 |
| backtrace:debug_hotplug_cpu | 0 | 52 | 13 |
| backtrace:kernel_init_freeable | 0 | 52 | 13 |
+------------------------------------------+------------+------------+------------+
[ 2.795299] Key type trusted registered
[ 2.797960] Key type encrypted registered
[ 2.800424] Unregister pv shared memory for cpu 0
[ 2.847203] BUG: unable to handle kernel paging request at 0000000000016f29
[ 2.849384] IP: [<ffffffff812189da>] cpu_vm_stats_fold+0x10a/0x180
[ 2.851271] PGD 0
[ 2.852450] Oops: 0000 [#1] SMP
[ 2.853953] Modules linked in:
[ 2.855216] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc1-00004-g970df71 #1
[ 2.857632] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 2.860605] task: ffff8800101c4b40 ti: ffff8800101c8000 task.ti: ffff8800101c8000
[ 2.863090] RIP: 0010:[<ffffffff812189da>] [<ffffffff812189da>] cpu_vm_stats_fold+0x10a/0x180
[ 2.865892] RSP: 0000:ffff8800101cbbf0 EFLAGS: 00010246
[ 2.867414] RAX: ffff880011529000 RBX: 0000000000000000 RCX: 0000000000000000
[ 2.869252] RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff8206d368
[ 2.871096] RBP: ffff8800101cbca0 R08: ffff88001152cc88 R09: 0000000000016f28
[ 2.872898] R10: ffffea00003ca2a0 R11: 0000000000000002 R12: ffff8800101cbc14
[ 2.874682] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000fffffff7
[ 2.876604] FS: 0000000000000000(0000) GS:ffff880011300000(0000) knlGS:0000000000000000
[ 2.879359] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.881003] CR2: 0000000000016f29 CR3: 0000000001c06000 CR4: 00000000000006e0
[ 2.882868] Stack:
[ 2.883886] 0000000011216f58 0000000000000000 0000000000000000 0000000000000000
[ 2.887027] 0000000800000000 00000000fffffff3 0000000000000000 0000000000000000
[ 2.890299] 0000000100000000 0000000000000008 0000000000000001 0000000000000000
[ 2.893633] Call Trace:
[ 2.894898] [<ffffffff811f4e9f>] page_alloc_cpu_notify+0x4f/0x60
[ 2.896784] [<ffffffff810f011d>] notifier_call_chain+0x5d/0xb0
[ 2.898731] [<ffffffff810f022e>] __raw_notifier_call_chain+0xe/0x10
[ 2.900662] [<ffffffff810c3486>] __cpu_notify+0x36/0x50
[ 2.902482] [<ffffffff810c35aa>] cpu_notify_nofail+0x1a/0x50
[ 2.906200] [<ffffffff810c35e0>] ? cpu_notify_nofail+0x50/0x50
[ 2.908022] [<ffffffff810c3606>] notify_dead+0x26/0x110
[ 2.909880] [<ffffffff810c35e0>] ? cpu_notify_nofail+0x50/0x50
[ 2.913145] [<ffffffff810c3f29>] cpuhp_invoke_callback+0x79/0x1b0
[ 2.914975] [<ffffffff810c4358>] cpuhp_down_callbacks+0x58/0xe0
[ 2.916724] [<ffffffff8179a08f>] _cpu_down+0x19f/0x1f0
[ 2.918560] [<ffffffff810c522e>] do_cpu_down+0x4e/0x70
[ 2.920232] [<ffffffff810c5260>] cpu_down+0x10/0x20
[ 2.921866] [<ffffffff81030340>] _debug_hotplug_cpu+0xa0/0xf0
[ 2.923656] [<ffffffff82090cdb>] ? topology_init+0x9f/0x9f
[ 2.926458] [<ffffffff82090ce8>] debug_hotplug_cpu+0xd/0x11
[ 2.928153] [<ffffffff8100041e>] do_one_initcall+0xde/0x2b0
[ 2.930113] [<ffffffff8208645f>] kernel_init_freeable+0x113/0x1d6
[ 2.932531] [<ffffffff8179945e>] kernel_init+0xe/0x180
[ 2.938010] [<ffffffff817a9de2>] ret_from_fork+0x22/0x40
[ 2.939919] [<ffffffff81799450>] ? rest_init+0x90/0x90
[ 2.941686] Code: 48 89 c7 e8 f9 dc ff ff 48 85 c0 0f 85 7a ff ff ff e8 4b dc ff ff 48 85 c0 74 5f 4c 8b 88 80 3c 00 00 4c 8d 80 88 3c 00 00 31 d2 <41> 0f be 4c 11 01 31 f6 84 c9 40 0f 95 c6 48 83 c6 02 48 83 04
[ 2.954461] RIP [<ffffffff812189da>] cpu_vm_stats_fold+0x10a/0x180
[ 2.956475] RSP <ffff8800101cbbf0>
[ 2.957900] CR2: 0000000000016f29
[ 2.959336] ---[ end trace ba236c6a755d1712 ]---
[ 2.960801] Kernel panic - not syncing: Fatal exception
git bisect start 84051050531602bc1d427bfc27d39fb8e2a6e23f f55532a0c0b8bb6148f4e07853b876ef73bc69ca --
git bisect bad 58766773d8b58762bea392f9f179e2ea5e602e2a # 22:29 0- 11 Merge 'linux-review/Lars-Peter-Clausen/usb-gadget-f_fs-Fix-EFAULT-generation-for-async-read-operations/20160330-201655' into devel-catchup-201603302038
git bisect bad 57cb0975edee7a62820dbc2dcbefe7a159687e71 # 22:29 0- 39 Merge 'linux-review/Shubhangi-Shrivastava/drm-i915-Splitting-intel_dp_detect/20160330-203510' into devel-catchup-201603302038
git bisect good b4fe8cd840d422f83211b03cd9b97c482e159ebf # 22:36 66+ 0 0day base guard for 'devel-catchup-201603302038'
git bisect bad 46edea8c09c5dada2def7b4558b5d38781c9211a # 22:42 0- 47 Merge 'mel/mm-vmscan-node-lru-v3r10' into devel-catchup-201603302038
git bisect bad 404ff05311b002244746cfbed691f0d4c17a76f3 # 22:48 0- 25 mm, workingset: Make working set detection node-aware
git bisect bad a6013470b90d9a2c8d3da20b9ee20ec32b42c30b # 22:52 0- 36 mm, vmscan: Make kswapd reclaim in terms of nodes
git bisect good 7db93e3a253b53eefedfd27fcf391bc2cb02380b # 22:59 66+ 0 mm, vmscan: Move lru_lock to the node
git bisect bad ac8fbf7357e93ccb5887ff9fb123d5b16bd7504f # 23:04 0- 17 mm, vmscan: Begin reclaiming pages on a per-node basis
git bisect bad 970df71e432f080bee5548dd6ee6606943ef3236 # 23:09 0- 52 mm, vmscan: Move LRU lists to node
# first bad commit: [970df71e432f080bee5548dd6ee6606943ef3236] mm, vmscan: Move LRU lists to node
git bisect good 7db93e3a253b53eefedfd27fcf391bc2cb02380b # 23:12 190+ 0 mm, vmscan: Move lru_lock to the node
# extra tests with DEBUG_INFO
git bisect bad 970df71e432f080bee5548dd6ee6606943ef3236 # 23:16 0- 7 mm, vmscan: Move LRU lists to node
# extra tests on HEAD of linux-devel/devel-catchup-201603302038
git bisect bad 84051050531602bc1d427bfc27d39fb8e2a6e23f # 23:16 0- 13 0day head guard for 'devel-catchup-201603302038'
# extra tests on tree/branch mel/mm-vmscan-node-lru-v3r10
git bisect bad ddb4e8c2992639305e2ecadacb53ba9fe80718bc # 23:37 0- 7 mm: vmstat: Account per-zone stalls and pages skipped during reclaim
# extra tests on tree/branch linus/master
git bisect good 1993b176a8224e371e0732ffada7ab9eb3b0912b # 23:45 190+ 0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
# extra tests on tree/branch linux-next/master
git bisect good 67130d02fee17fd2176fff7d49d4f91ccbdede07 # 23:49 188+ 0 Add linux-next specific files for 20160330
This script may reproduce the error.
----------------------------------------------------------------------------
#!/bin/bash
kernel=$1
initrd=quantal-core-x86_64.cgz
wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-initrd $initrd
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
----------------------------------------------------------------------------
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
4 years, 3 months
[lkp] [x86/mm] 05024080c7: WARNING: CPU: 2 PID: 4250 at arch/x86/mm/tlb.c:410 flush_tlb_func+0x1b4/0x1c0()
by kernel test robot
FYI, we noticed the below Call Trace warning log showed with your commit.
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/pcid
commit 05024080c74d6a95ceac36a7c8aece0ed961aec7 ("x86/mm: Try to preserve old TLB entries using PCID")
[ 112.925662] perf interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 113.231394] perf interrupt took too long (5013 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 280.018660] ------------[ cut here ]------------
[ 280.018990] WARNING: CPU: 2 PID: 4250 at arch/x86/mm/tlb.c:410 flush_tlb_func+0x1b4/0x1c0()
[ 280.019560] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver netconsole sg sr_mod cdrom sd_mod dcdbas ata_generic coretemp pata_acpi snd_hda_codec_realtek kvm_intel snd_hda_codec_generic ata_piix kvm irqbypass i7core_edac crc32c_intel serio_raw snd_hda_codec_hdmi pcspkr edac_core libata snd_hda_intel firewire_ohci usb_storage snd_hda_codec firewire_core crc_itu_t snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore shpchp acpi_cpufreq broadcom bcm_phy_lib
[ 280.023594] CPU: 2 PID: 4250 Comm: mmap1_threads Not tainted 4.5.0-rc2-00217-g0502408 #3
[ 280.024087] Hardware name: Dell Inc. Studio XPS 8000/0X231R, BIOS A01 08/11/2009
[ 280.024579] ffffffff81bbd1b8 ffff88013fc83ee0 ffffffff8141d762 0000000000000000
[ 280.025213] ffff88013fc83f18 ffffffff81079486 ffff88013fc9ba40 ffff88013da4bc08
[ 280.025846] ffffffffffffffff ffff88013da4bc08 0000000100000000 ffff88013fc83f28
[ 280.026575] Call Trace:
[ 280.026822] <IRQ> [<ffffffff8141d762>] dump_stack+0x4b/0x69
[ 280.027238] [<ffffffff81079486>] warn_slowpath_common+0x86/0xc0
[ 280.027629] [<ffffffff8107957a>] warn_slowpath_null+0x1a/0x20
[ 280.027974] [<ffffffff8106a694>] flush_tlb_func+0x1b4/0x1c0
[ 280.028308] [<ffffffff8106a4e0>] ? do_flush_tlb_all+0x50/0x50
[ 280.028657] [<ffffffff810f8f0b>] flush_smp_call_function_queue+0x7b/0x160
[ 280.029046] [<ffffffff810f9a33>] generic_smp_call_function_single_interrupt+0x13/0x60
[ 280.029533] [<ffffffff8104d917>] smp_call_function_interrupt+0x27/0x40
[ 280.029903] [<ffffffff818db39c>] call_function_interrupt+0x8c/0xa0
[ 280.030266] <EOI> [<ffffffff810c481d>] ? rwsem_spin_on_owner+0x3d/0x90
[ 280.030744] [<ffffffff818d83b1>] rwsem_down_write_failed+0xe1/0x360
[ 280.031110] [<ffffffff8142b683>] call_rwsem_down_write_failed+0x13/0x20
[ 280.031489] [<ffffffff818d7cb0>] ? down_write+0x40/0x50
[ 280.031819] [<ffffffff811a6fc3>] vm_munmap+0x33/0x60
[ 280.032137] [<ffffffff811a7012>] SyS_munmap+0x22/0x30
[ 280.032451] [<ffffffff818d9cee>] entry_SYSCALL_64_fastpath+0x12/0x6d
[ 280.032821] ---[ end trace f27b71185e2f9b5f ]---
[ 280.032821] ---[ end trace f27b71185e2f9b5f ]---
To reproduce:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong Ye
4 years, 3 months
