linux-kernel - Re: [GIT pull] CPU hotplug updates for 4.9

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Mar 2017 17:20:39 +0000
From:   Bart Van Assche <Bart.VanAssche@...disk.com>
To:     "tglx@...utronix.de" <tglx@...utronix.de>
CC:     "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [GIT pull] CPU hotplug updates for 4.9

On Thu, 2017-03-09 at 11:22 +0100, Thomas Gleixner wrote:
> > In contrast with previous tests this morning I have been able to reproduce
> > this hang with kernel v4.10. So it's not a kernel v4.10 regression. But the
> > hang did not occur in a test with kernel v4.9.7. I assume this means that
> > the regression got introduced between the v4.9 and v4.10 kernels.
> 
> Is it always the x86_pkg_thermal init which locks up?

Hello Thomas,

Apparently not. Here are a few other call traces that appeared in the system
log:

INFO: task systemd-udevd:748 blocked for more than 480 seconds.
      Tainted: G          IO    4.11.0-rc1-dbg+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-udevd   D    0   748    518 0x00000104
Call Trace:
 __schedule+0x302/0xc30
 schedule+0x38/0x90
 schedule_timeout+0x255/0x490
 wait_for_completion+0x103/0x170
 cpuhp_issue_call+0xb9/0xe0
 __cpuhp_setup_state+0xf6/0x180
 coretemp_init+0x8d/0x1000 [coretemp]
 do_one_initcall+0x3e/0x170
 do_init_module+0x5a/0x1ed
 load_module+0x2339/0x2a40
 SYSC_finit_module+0xbc/0xf0
 SyS_finit_module+0x9/0x10
 do_syscall_64+0x57/0x140
 entry_SYSCALL64_slow_path+0x25/0x25
Showing all locks held in the system:
2 locks held by khungtaskd/91:
 #0:  (rcu_read_lock){......}, at: [<ffffffff8111a6f0>] watchdog+0xa0/0x5d0
 #1:  (tasklist_lock){.+.?..}, at: [<ffffffff810bf36d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by systemd-udevd/748:
 #0:  (cpu_hotplug.dep_map){++++++}, at: [<ffffffff8106712d>] get_online_cpus+0x2d/0x80


The call trace below appeared because I ran echo w > /proc/sysrq-trigger to
check whether any kernel thread hung:

sysrq: SysRq : Show Blocked State
  task                        PC stack   pid father
systemd-udevd   D    0   738    505 0x00000104
Call Trace:
 __schedule+0x302/0xc30
 schedule+0x38/0x90
 schedule_timeout+0x255/0x490
 wait_for_completion+0x103/0x170
 cpuhp_issue_call+0xb9/0xe0
 __cpuhp_setup_state+0xf6/0x180
 kvm_timer_init+0x52/0xd0 [kvm]
 kvm_arch_init+0xd2/0x180 [kvm]
 kvm_init+0x1d/0x2b0 [kvm]
 vmx_init+0x21/0x628 [kvm_intel]
 do_one_initcall+0x3e/0x170
 do_init_module+0x5a/0x1ed
 load_module+0x2339/0x2a40
 SYSC_finit_module+0xbc/0xf0
 SyS_finit_module+0x9/0x10
 do_syscall_64+0x57/0x140
 entry_SYSCALL64_slow_path+0x25/0x25

Bart.