linux-kernel - native_smp_send_reschedule() splat from rt_mutex

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-next>] [day] [month] [year] [list]

Message-Id: <20170918165110.GA9975@linux.vnet.ibm.com>
Date:   Mon, 18 Sep 2017 09:51:10 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     peterz@...radead.org, mingo@...hat.com
Cc:     linux-kernel@...r.kernel.org, bigeasy@...utronix.de,
        tglx@...utronix.de
Subject: native_smp_send_reschedule() splat from rt_mutex_lock()?

Hello!

Just moved ahead to v4.14-rc1, and I am seeing a native_smp_send_reschedule()
splat from rt_mutex_lock():

[11072.586518] sched: Unexpected reschedule of offline CPU#6!
[11072.587578] ------------[ cut here ]------------
[11072.588563] WARNING: CPU: 0 PID: 59 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40
[11072.591543] Modules linked in:
[11072.591543] CPU: 0 PID: 59 Comm: rcub/10 Not tainted 4.14.0-rc1+ #1
[11072.592572] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[11072.594602] task: ffff9928de772640 task.stack: ffff9f580031c000
[11072.596655] RIP: 0010:native_smp_send_reschedule+0x37/0x40
[11072.597599] RSP: 0000:ffff9f580031fd10 EFLAGS: 00010082
[11072.598572] RAX: 000000000000002e RBX: ffff9928dd3fd940 RCX: 0000000000000004
[11072.599693] RDX: 0000000080000004 RSI: 0000000000000086 RDI: 00000000ffffffff
[11072.601602] RBP: ffff9f580031fd10 R08: 000000000008f316 R09: 0000000000007e52
[11072.603563] R10: 0000000000000001 R11: ffffffffb957c2cd R12: 0000000000000006
[11072.604610] R13: ffff9928de772640 R14: 0000000000000061 R15: ffff9928deb991c0
[11072.606537] FS:  0000000000000000(0000) GS:ffff9928dea00000(0000) knlGS:0000000000000000
[11072.607654] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[11072.608646] CR2: 0000000009728b40 CR3: 000000001b640000 CR4: 00000000000006f0
[11072.610596] Call Trace:
[11072.611531]  resched_curr+0x61/0xd0
[11072.611531]  switched_to_rt+0x8f/0xa0
[11072.612647]  rt_mutex_setprio+0x25c/0x410
[11072.613591]  task_blocks_on_rt_mutex+0x1b3/0x1f0
[11072.614601]  rt_mutex_slowlock+0xa9/0x1e0
[11072.615567]  rt_mutex_lock+0x29/0x30
[11072.615567]  rcu_boost_kthread+0x127/0x3c0
[11072.616618]  kthread+0x104/0x140
[11072.617641]  ? rcu_report_unblock_qs_rnp+0x90/0x90
[11072.618565]  ? kthread_create_on_node+0x40/0x40
[11072.619509]  ret_from_fork+0x22/0x30
[11072.620593] Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 84 67 c5 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 70 c4 fc b7 e8 05 b3 06 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 f2 d4 13 02 85 c0 75 38 55 48 

In theory, I could work around this by excluding CPU-hotplug operations
while doing RCU priority boosting, but in practice I am very much hoping
that there is a more reasonable solution out there...

							Thanx, Paul