Messages in this thread | | | Date | Fri, 7 Nov 2014 10:39:48 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: hotplug thread issues |
| |
On Thu, 6 Nov 2014, Peter Zijlstra wrote:
> Hi Thomas, > > So there have been some reports on hitting: > > BUG_ON(td->cpu != smp_processor_id()); > > in smpboot_thread_fn. > > Now I've been staring at this for a wee bit today and I've found two > issues, but I'm not sure either are enough to explain the observed. > > 1) smpboot_register_percpu_thread() seems to lack serialization against > hotplug. It has a for_each_online() loop, but no get_online_cpus() -- > unlike smpboot_unregister_percpu_thread, which does. > > Typical usage like spawn_ksoftirqd() should be fine, they're early > init calls and those run before we bring up the other CPUs. Therefore > this does not explain the observation that its ksoftirqd/n triggering > the BUG. > > However, the usage in proc_dowatchdog() is susceptible to this race > and its entirely possible to go wrong there.
Hmm. Need to have a look.
> > 2) the usage of __set_current_state(TASK_PARKED) in __kthread_parkme() > is wrong AFAICT, one should always use set_current_state() for > setting !TASK_RUNNING state. The comment with set_current_state() > explains why. > > This would've allowed the test_bit(KTHREAD_SHOULD_PARK) load to have > been satisfied before the store of TASK_PARKED.
My bad. Can you send a proper patch addressing that issue please? That should be tagged stable as well I guess.
Thanks,
tglx
| |