linux-kernel - Re: [PATCH] RFC: x86/smp: use printk_deferred in native_smp_send

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190508074420.GB15704@jagdpanzerIV>
Date:   Wed, 8 May 2019 16:44:20 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org, Nicolai Stange <nstange@...e.de>,
        Thomas Gleixner <tglx@...utronix.de>
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