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
| ||
|
Date: Wed, 23 Dec 2015 13:15:46 +0900 From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> To: Jan Kara <jack@...e.cz> Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Petr Mladek <pmladek@...e.cz>, KY Sri nivasan <kys@...rosoft.com>, Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing too long On (12/23/15 12:57), Sergey Senozhatsky wrote: [..] > > > can we replace this oops_in_progress check with something more reliable? > > > > > > CPU0 CPU1 - CPUN > > > panic() > > > local_irq_disable() executing foo() with irqs disabled, > > > console_verbose() or processing an extremely long irq handler. > > > bust_spinlocks() > > > oops_in_progress++ > > or we huge enough number of CPUs, `deep' stack > traces, slow serial and CPU doing dump_stack() > under raw_spin_lock(&stop_lock), so it can take > longer than 1 second to print the stacks and > thus panic CPU will set oops_in_progress back > to 0. > > > > smp_send_stop() > > > > > > bust_spinlocks() > > > oops_in_progress-- ok, IPI arrives > > > dump_stack()/printk()/etc from IPI_CPU_STOP > > > "while (1) cpu_relax()" with irq/fiq disabled/halt/etc. > > > > > > smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is arch specific, > > > and some platforms don't do any IPI-delivered (e.g. via num_online_cpus()) checks at > > > all. Some do. For example, arm/arm64: > > > > > > void smp_send_stop(void) > > > ... > > > /* Wait up to one second for other CPUs to stop */ > > > timeout = USEC_PER_SEC; > > > while (num_online_cpus() > 1 && timeout--) > > > udelay(1); > > > > > > if (num_online_cpus() > 1) > > > pr_warn("SMP: failed to stop secondary CPUs\n"); > > > ... > > > > > > > > > so there are non-zero chances that IPI will arrive to CPU after 'oops_in_progress--', > > > and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost. > > > > > > > > > bust_spinlocks(0) does > > > ... > > > if (--oops_in_progress == 0) > > > wake_up_klogd(); > > > ... > > > > > > but local cpu has irqs disabled and `panic_timeout' can be zero. well, if panic_timeout != 0, then wake_up_klogd() calls irq_work_queue() which schedule_work. what if we have the following CPU0 CPU1 - CPUN foo preempt_disable bar panic irq/fiq disable schedule_work while (1) cpu_relax -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists