lkml.org 
[lkml]   [2014]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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




\
 
 \ /
  Last update: 2014-11-07 11:21    [W:0.051 / U:2.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site