From: Mike Galbraith <hidden> Date: 2018-08-18 10:29:31
On Fri, 2018-08-17 at 16:23 -0400, Steven Rostedt wrote:
Pulling in stable releases into v4.14-rt I triggered this with my CPU
hotplug test:
------------[ cut here ]------------
kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd shpchp i2c_i801 soundcore floppy i915 drm_kms_helper drm fb_sys_fops sysimgblt sysfillrect syscopyarea i2c_algo_bit iosf_mbi video [last unloaded: speedstep_lib]
CPU: 1 PID: 2944 Comm: mkdumprd Not tainted 4.14.63-test-rt40+ #782
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
task: ffff880037888d80 task.stack: ffffc90000538000
RIP: 0010:select_fallback_rq+0xc3/0x122
I noticed this upstream, and had started hunting for the origin, but
had thought that 4.14-rt was OK. Clearly not the case, but it's not
4.14.60.. stable changes interacting badly either, virgin 4.14.59-rt37
just reproduced in a vm clone of my workstation.
-Mike
From: Mike Galbraith <hidden> Date: 2018-08-18 13:13:32
On Sat, 2018-08-18 at 12:29 +0200, Mike Galbraith wrote:
On Fri, 2018-08-17 at 16:23 -0400, Steven Rostedt wrote:
quoted
Pulling in stable releases into v4.14-rt I triggered this with my CPU
hotplug test:
------------[ cut here ]------------
kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd shpchp i2c_i801 soundcore floppy i915 drm_kms_helper drm fb_sys_fops sysimgblt sysfillrect syscopyarea i2c_algo_bit iosf_mbi video [last unloaded: speedstep_lib]
CPU: 1 PID: 2944 Comm: mkdumprd Not tainted 4.14.63-test-rt40+ #782
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
task: ffff880037888d80 task.stack: ffffc90000538000
RIP: 0010:select_fallback_rq+0xc3/0x122
I noticed this upstream, and had started hunting for the origin, but
had thought that 4.14-rt was OK. Clearly not the case, but it's not
4.14.60.. stable changes interacting badly either, virgin 4.14.59-rt37
just reproduced in a vm clone of my workstation.
4.15.18-rt37 (4.14-rt rolled forward) does not reproduce, nor does
4.16.18-rt12, but 4.17.0-rt5 (v4.16.12-rt5 rolled forward) does, so
seems it has be something from the 4.17 cycle that went back to 4.14-
stable after 4.1[56]-stable trees went extinct.
-Mike
From: Mike Galbraith <hidden> Date: 2018-08-19 06:29:16
On Sat, 2018-08-18 at 15:13 +0200, Mike Galbraith wrote:
seems it has be something from the 4.17 cycle that went back to 4.14-
stable after 4.1[56]-stable trees went extinct.
See ("sched/core: Require cpu_active() in select_task_rq(), for user tasks")
Fix it like so?
sched: Allow pinned user tasks to be awakened to the CPU they pinned
Since 7af443ee16976, select_fallback_rq() will BUG() if the CPU to
which a task has pinned itself and pinned becomes !cpu_active()
while it slept. Serving a 10 megaton eviction notice is neither
helpful nor required, the task will migrate when it can do so.
Signed-off-by: Mike Galbraith <redacted>
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Steven Rostedt <rostedt@goodmis.org> Date: 2018-08-22 16:17:55
On Sun, 19 Aug 2018 08:28:35 +0200
Mike Galbraith [off-list ref] wrote:
On Sat, 2018-08-18 at 15:13 +0200, Mike Galbraith wrote:
quoted
seems it has be something from the 4.17 cycle that went back to 4.14-
stable after 4.1[56]-stable trees went extinct.
See ("sched/core: Require cpu_active() in select_task_rq(), for user tasks")
Fix it like so?
sched: Allow pinned user tasks to be awakened to the CPU they pinned
Since 7af443ee16976, select_fallback_rq() will BUG() if the CPU to
which a task has pinned itself and pinned becomes !cpu_active()
while it slept. Serving a 10 megaton eviction notice is neither
helpful nor required, the task will migrate when it can do so.
This seems to fix the issue that I was seeing. Thanks!
I'll add this to my repo as well.
-- Steve
From: Steven Rostedt <rostedt@goodmis.org> Date: 2018-08-22 16:33:21
Sebastian,
On Wed, 22 Aug 2018 12:17:49 -0400
Steven Rostedt [off-list ref] wrote:
On Sun, 19 Aug 2018 08:28:35 +0200
Mike Galbraith [off-list ref] wrote:
quoted
On Sat, 2018-08-18 at 15:13 +0200, Mike Galbraith wrote:
quoted
seems it has be something from the 4.17 cycle that went back to 4.14-
stable after 4.1[56]-stable trees went extinct.
See ("sched/core: Require cpu_active() in select_task_rq(), for user tasks")
Fix it like so?
sched: Allow pinned user tasks to be awakened to the CPU they pinned
Since 7af443ee16976, select_fallback_rq() will BUG() if the CPU to
which a task has pinned itself and pinned becomes !cpu_active()
while it slept. Serving a 10 megaton eviction notice is neither
helpful nor required, the task will migrate when it can do so.
This seems to fix the issue that I was seeing. Thanks!
I'll add this to my repo as well.
I'm going to hold off on pulling this in until I see it in your tree,
because a stable RT branch should not carry anything that isn't in the
head RT tree. And it appears that this can affect your repo too.
-- Steve
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2018-08-29 14:00:17
On 2018-08-22 12:33:15 [-0400], Steven Rostedt wrote:
I'm going to hold off on pulling this in until I see it in your tree,
because a stable RT branch should not carry anything that isn't in the
head RT tree. And it appears that this can affect your repo too.