Messages in this thread | | | Date | Wed, 8 May 2019 16:44:20 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] RFC: x86/smp: use printk_deferred in native_smp_send_reschedule |
| |
On (05/07/19 19:33), Daniel Vetter wrote: [..] > - make the console_trylock trylock also the spinlock. This works in > the limited case of the console_lock use-case, but doesn't fix the > same semaphore.lock acquisition in the up() path in console_unlock, > which we can't avoid with a trylock. > > - move the wake_up_process in up() out from under the semaphore.lock > spinlock critical section. Again this works for the limited case of > the console_lock, and does fully break the cycle for this lock. > Unfortunately there's still plenty of scheduler related locks that > wake_up_process needs, so the loop is still there, just with a few > less locks involved. > > Hence now third attempt, trying to fix this by using printk_deferred() > instead of the normal printk that WARN() uses. > native_smp_send_reschedule is only called from scheduler related code, > which has to use printk_deferred due to this locking recursion, so > this seems consistent. > > It has the unfortunate downside that we're losing the backtrace though > (I didn't find a printk_deferred version of WARN, and I'm not sure > it's a bright idea to dump that much using printk_deferred.)
I'm catching up with the emails now (was offline for almost 2 weeks), so I haven't seen [yet] all of the previous patches/discussions.
[..] > static void native_smp_send_reschedule(int cpu) > { > if (unlikely(cpu_is_offline(cpu))) { > - WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", cpu); > + printk_deferred(KERN_WARNING > + "sched: Unexpected reschedule of offline CPU#%d!\n", cpu); > return; > } > apic->send_IPI(cpu, RESCHEDULE_VECTOR);
Hmm, One thing to notice here is that the CPU in question is offline-ed, and printk_deferred() is a per-CPU type of deferred printk(). So the following thing
__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT); irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
might not print anything at all. In this particular case we always need another CPU to do console_unlock(), since this_cpu() is not really expected to do wake_up_klogd_work_func()->console_unlock().
-ss
| |