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: Thu, 31 Dec 2015 11:44:59 +0900 From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> To: Jan Kara <jack@...e.cz> Cc: Sergey Senozhatsky <sergey.senozhatsky@...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, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing too long Hello, On (12/22/15 14:47), Jan Kara wrote: [..] > +int printk_deferred(const char *fmt, ...) > +{ > + va_list args; > + int r; > + > + va_start(args, fmt); > + r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args); > + va_end(args); > + > + return r; > +} [..] > @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level, > logbuf_cpu = UINT_MAX; > raw_spin_unlock(&logbuf_lock); > lockdep_on(); > + /* > + * By default we print message to console asynchronously so that kernel > + * doesn't get stalled due to slow serial console. That can lead to > + * softlockups, lost interrupts, or userspace timing out under heavy > + * printing load. > + * > + * However we resort to synchronous printing of messages during early > + * boot, when oops is in progress, or when synchronous printing was > + * explicitely requested by kernel parameter. > + */ > + if (keventd_up() && !oops_in_progress && !sync_print) { > + __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT); > + irq_work_queue(this_cpu_ptr(&wake_up_klogd_work)); > + } else > + sync_print = true; > local_irq_restore(flags); So this fixes printk() and printk_deferred(), but it doesn't address any of the direct and indirect console_lock/console_unlock callers. for example, direct: ~/_mmots$ git grep console_unlock | egrep -v "printk\.c|panic\.c|console\.h" | wc -l 199 indirect (e.g. via console_devices()): ~/_mmots$ git grep console_device | egrep -v "printk\.c|panic\.c|console\.h|_console_device" | wc -l 4 One of those indirect callers is tty_lookup_driver(), called from tty_open(). Which is quite big to ignore, I suspect. A user space process opening a tty can end up doing that while (1) call_console_drivers() loop, I suspect. At least nothing prevents it, at a glance. A side note, isn't it too often to cond_resched() from console_unlock()? What if we have 10000000 very short printk() messages (e.g. no more than 32 chars). -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