On Mon, 14 Apr 2014 12:03:35 +0200 Ingo Molnar <mi...@kernel.org> wrote:
> > * Igor Mammedov <imamm...@redhat.com> wrote: > > > On Mon, 14 Apr 2014 11:16:00 +0200 > > Ingo Molnar <mi...@kernel.org> wrote: > > > > > > > > * Igor Mammedov <imamm...@redhat.com> wrote: > > > > > > > /* > > > > + * wait for ACK from master CPU before continuing > > > > + * with AP initialization > > > > + */ > > > > + cpumask_set_cpu(cpu, cpu_initialized_mask); > > > > + while (!cpumask_test_cpu(cpu, cpu_callout_mask)) > > > > + cpu_relax(); > > > > > > > + /* > > > > + * wait for ACK from master CPU before continuing > > > > + * with AP initialization > > > > + */ > > > > + cpumask_set_cpu(cpu, cpu_initialized_mask); > > > > + while (!cpumask_test_cpu(cpu, cpu_callout_mask)) > > > > + cpu_relax(); > > > > > > That repetitive pattern could be stuck into a properly named helper > > > inline function. > > sure > > > > > (Also, before the cpumask_set_cpu() we should probably do a WARN_ON() > > > if the bit is already set.) > > The reason why there is no any WARN_ON or likes is that printk is quite > > complicated, takes looks and so on. [...] > > [ Yeah, I too heard that printk(), like a pretty girl, is complicated > and makes people look twice. ] > > > [...] So it's not safe at this point since > > CPU could be shot down by any time by INIT/SIPI until it's out of > > cpu_callout_mask loop. > > Not sure where you got that from, but it's not a valid concern really: > the only place where we don't want to do a printk() is in printk code > itself. > > Debug warnings, by definition, should never trigger. If they trigger > then they will very likely not cause lockups, but will cause the bug > to be fixed. ok, I'll add WARN_ON in cpu_init() as you've suggested. > Thanks, > > Ingo -- Regards, Igor -- 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/
