On 04/15, Robin Holt wrote: > > On Sat, Apr 13, 2013 at 06:30:22PM +0200, Oleg Nesterov wrote: > > On 04/12, Robin Holt wrote: > > > > > > +void migrate_to_boot_cpu(void) > > > +{ > > > + /* The boot cpu is always logical cpu 0 */ > > > + int reboot_cpu_id = 0; > > > + > > > + /* Make certain the cpu I'm about to reboot on is online */ > > > + if (!cpu_online(reboot_cpu_id)) > > > + reboot_cpu_id = smp_processor_id(); > > > + > > > + /* Make certain I only run on the appropriate processor */ > > > + set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id)); > > > > This is only theoretical, but perhaps it makes sense to set > > PF_THREAD_BOUND before set_cpus_allowed_ptr() ? To prevent the > > race with another thread doing sched_setaffinity(). > > I don't quite understand this comment. We are migrating our own thread. > How does setting PF_THREAD_BOUND have any effect?
Suppose that another thread does, say, sys_sched_setaffinity(our_pid) right after set_cpus_allowed_ptr(). If we set PF_THREAD_BOUND the next set_cpus_allowed() will fail. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/