From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B90BE9C for ; Tue, 19 Jul 2016 03:47:17 +0000 (UTC) Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E92F236 for ; Tue, 19 Jul 2016 03:47:17 +0000 (UTC) Received: by mail-pf0-f195.google.com with SMTP id h186so490704pfg.2 for ; Mon, 18 Jul 2016 20:47:17 -0700 (PDT) Date: Tue, 19 Jul 2016 12:47:17 +0900 From: Sergey Senozhatsky To: ksummit-discuss@lists.linuxfoundation.org Message-ID: <20160719034717.GA24189@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Cc: Petr Mladek , Tetsuo Handa , Viresh Kumar , Tejun Heo , Jiri Kosina Subject: [Ksummit-discuss] [TECH TOPIC] asynchronous printk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello, Wondering if anyone will be interested in printk-related topics (or we can handle it in the mailing list). What I have on my list is: - synchronous printk() printk() prints messages from kernel printk buffer until the buffer is empty. When serial console is attached, printing is slow and thus other CPUs in the system have plenty of time to append new messages to the buffer while one CPU is printing. Thus the CPU can spend unbounded amount of time doing printing in console_unlock(). This is especially serious problem if the printk() calling console_unlock() was called with interrupts disabled, or from IRQ, or from spin_lock protected section (if the spinlock is contended), etc. etc. IOW, printk() is quite dangerous function to call in some cases, it can cause different types of lockups (soft, hard, spinlock), stalls and so on. we have some progress on this side. printk() can offload printing from sensitive and unsafe contexts to a schedulable printk_kthread context (a special purpose printing kthread). but "The whole idea remains worrisome", per Andrew :) - synchronous console_unlock() there are many places that need to lock and unlock console semaphore for purposes other than flushing the log_buf. apart from 'in-kernel' users (e.g. video, etc.) some of those console_lock/console_unlock are done by user-space apps in system calls. examples: = open /dev/ttyX console_unlock() ... console_lock() tty_open() console_device() chrdev_open() SyS_open() = cat /proc/consoles console_unlock() c_stop() ... console_lock() c_start() seq_read() proc_reg_read() vfs_read() SyS_read() = and so on. so user-space apps can print kernel messages. which is not really nice, I think. I have a patch that makes console_unlock() async as well; but we still have console_lock() that is sync. thus - console semaphore not every console_lock() caller has an intention to modify console driver state, or console drivers list. so we probably can start distinguish READ console drivers list access and WRITE access. - KERN_CONT handling the comment for KERN_CONT in include/linux/kern_levels.h suggests that /* * Annotation for a "continued" line of log printout (only done after a * line that had no enclosing \n). Only to be used by core/arch code * during early bootup (a continued line is not SMP-safe otherwise). */ #define KERN_CONT→ "" the thing is that people want cont lines in SMP-mode, and people do use KERN_CONT in SMP mode. e.g. cgroups, ACPI, etc. internally printk maintains a single cont buffer and, thus, there are numerous if-s and else-s to cope with the fact that it can be used in SMP-mode. so the question is -- is it the right time to make KERN_CONT SMP-safe? may be we can move cont buffers into per-CPU and add a new API for cont printing -- pr_cont_begin()/pr_cont_end(). so the usage will be something like this: + pr_cont_begin(); /* preempt disable */ for (...) pr_cont("foo .... " .....); + pr_cont_end(); /* preempt enable */ Petr Mladek has another idea: http://marc.info/?l=linux-kernel&m=146860197621876 The list of potential attendees (not in any particular order, most likely incomplete) Jan Kara Petr Mladek Andrew Morton Jiri Kosina Tejun Heo Hannes Reinecke Viresh Kumar Steven Rostedt Sergey Senozhatsky -ss