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

\
 
 \ /
  Last update: 2019-05-08 09:45    [W:0.385 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site