public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* non-atomic test victim #1
@ 2002-09-17 20:33 Robert Love
  0 siblings, 0 replies; only message in thread
From: Robert Love @ 2002-09-17 20:33 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel

Current kernel with the non-atomic test I sent, SMP with preemption.

I only get two triggers, both during boot.  They are on migration_thread
and ksoftirqd startup.  The problem lies in set_cpus_allowed():

    Trace; c0116ac4 <schedule+a4/4b0>
    Trace; c011731a <wait_for_completion+11a/1d0>
    Trace; c0116f30 <default_wake_function+0/40>
    Trace; c0115d02 <try_to_wake_up+312/320>
    Trace; c0116f30 <default_wake_function+0/40>
    Trace; c0118f0f <set_cpus_allowed+22f/250>
    Trace; c0118f7d <migration_thread+4d/590>
    Trace; c0118f30 <migration_thread+0/590>
    Trace; c0118f30 <migration_thread+0/590>
    Trace; c010586d <kernel_thread_helper+5/18>

It is obviously the preempt_disable() which we hold past the wake_up().

The issue is that, without this preempt_disable() there have been
observed crashes, especially on large n-way machines.  Both Andrew
Morton and Anton Blanchard have reported the problem and that this fixes
it.

Question is, why does set_cpus_allowed() need it?  I do not see it... it
must be an issue with an early preemption and the resulting
migration_thread?

Ingo, ideas?

	Robert Love



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2002-09-17 20:28 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-17 20:33 non-atomic test victim #1 Robert Love

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox