From: Darren Hart <dvhltc@us.ibm.com>
To: linuxppc-dev@ozlabs.org
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Gautham R Shenoy <ego@in.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Will Schmidt <willschm@us.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
Date: Thu, 22 Jul 2010 11:24:13 -0700 [thread overview]
Message-ID: <4C488CCD.60004@us.ibm.com> (raw)
While testing CPU offline/online, we hit various preempt_count related
bugs. Various hacks have been employed for several theoretical corner
cases. One situation however is perfectly repeatable on 2.6.33.6 with
CONFIG_PREEMPT=y.
BUG: scheduling while atomic: swapper/0/0x00000065
Modules linked in: autofs4 sunrpc ipv6 dm_mirror dm_region_hash dm_log
dm_mod ehea sg ext4 jbd2 mbcache sd_mod crc_t10dif ibmvscsic
scsi_transport_srp scsi_tgt [last unloaded: scsi_wait_scan]
Call Trace:
[c00000010e9e39f0] [c0000000000144d4] .show_stack+0x74/0x1c0 (unreliable)
[c00000010e9e3aa0] [c00000000007a680] .__schedule_bug+0xa0/0xb0
[c00000010e9e3b30] [c00000000056dea4] .schedule+0x7a4/0xd60
[c00000010e9e3cd0] [c000000000016be8] .cpu_idle+0x1f8/0x220
[c00000010e9e3d80] [c00000000057d858] .start_secondary+0x388/0x3c0
[c00000010e9e3e30] [c000000000008278] .start_secondary_resume+0x10/0x14
With some instrumentation we were able to determine that the
preempt_count() appears to change across the extended_cede_processor()
call. Specifically across the plpar_hcall_norets(H_CEDE) call. On
PREEMPT_RT we call this with preempt_count=1 and return with
preempt_count=0xffffffff. On mainline with CONFIG_PREEMPT=y, the value
is different (0x65) but is still incorrect.
Also of interest is that this path
cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
enters with a preempt_count=1 if it wasn't corrupted across the hcall.
The early boot path from _start however appears to call
start_secondary() with a preempt_count of 0.
The following patch is most certainly not correct, but it does eliminate
the situation on mainline 100% of the time (there is still a 25%
reproduction rate on PREEMPT_RT). Can someone comment on:
1) How can the preempt_count() get mangled across the H_CEDE hcall?
2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
Hacked-up-by: Darren Hart <dvhltc@us.ibm.com>
Index: linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c
===================================================================
--- linux-2.6.33.6.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -138,6 +138,7 @@ static void pseries_mach_cpu_die(void)
* Kernel stack will be reset and start_secondary()
* will be called to continue the online operation.
*/
+ preempt_count() = 0;
start_secondary_resume();
}
}
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next reply other threads:[~2010-07-22 18:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 18:24 Darren Hart [this message]
2010-07-22 18:36 ` [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries Darren Hart
2010-07-22 18:38 ` Thomas Gleixner
2010-08-10 22:36 ` Darren Hart
2010-07-22 22:25 ` Benjamin Herrenschmidt
2010-07-22 23:57 ` Darren Hart
2010-07-23 4:44 ` Darren Hart
2010-07-23 5:08 ` Vaidyanathan Srinivasan
2010-07-23 5:11 ` Benjamin Herrenschmidt
2010-07-23 7:07 ` Vaidyanathan Srinivasan
2010-08-05 4:45 ` Darren Hart
2010-08-05 11:06 ` Vaidyanathan Srinivasan
2010-08-05 12:26 ` Thomas Gleixner
2010-07-23 5:09 ` Benjamin Herrenschmidt
2010-08-06 2:19 ` Darren Hart
2010-08-06 5:09 ` Vaidyanathan Srinivasan
2010-08-06 7:13 ` Darren Hart
2010-07-23 14:39 ` Will Schmidt
2010-08-04 13:44 ` Darren Hart
2010-08-19 15:58 ` Ankita Garg
2010-08-19 18:58 ` Will Schmidt
2010-08-23 22:20 ` Darren Hart
2010-08-31 7:12 ` Darren Hart
2010-09-01 5:54 ` Michael Ellerman
2010-09-01 15:10 ` Darren Hart
2010-09-01 18:47 ` Darren Hart
2010-09-01 19:59 ` Steven Rostedt
2010-09-01 20:42 ` Darren Hart
2010-09-02 1:02 ` Michael Neuling
2010-09-02 4:06 ` Steven Rostedt
2010-09-02 6:04 ` Darren Hart
2010-09-03 20:10 ` Will Schmidt
2010-09-02 23:04 ` Michael Neuling
2010-09-03 0:08 ` Darren Hart
2010-09-02 3:46 ` Michael Neuling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C488CCD.60004@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=ego@in.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=willschm@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.