Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3249898imu; Sat, 24 Nov 2018 01:04:07 -0800 (PST) X-Google-Smtp-Source: AFSGD/XmZkkJaIvm+TG9PlNBolx1lfm+dsXTEvZoZXRMIzVuH7/78AIeprSnnvo9utMnw4f/kGgZ X-Received: by 2002:a65:564b:: with SMTP id m11mr16745871pgs.216.1543050247947; Sat, 24 Nov 2018 01:04:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543050247; cv=none; d=google.com; s=arc-20160816; b=b+O8pyug4/kTOtmsizUDy4lS4bnsNFvVn1mxEKoxv1xR25Jla6qB3lkO1xM5UASy7I uylNvpaS7MeXMOrxO1Gmu2Unp6eASSyYKNtPmjWsuZklLiGR9IG20LTH6lN1EMItlcc4 sBYI6ZSYBMcrPfn0xsjDBonAqV75Cg5+NLXKyg4G3mg36prRK7vPaJhwt9UOMvs7dIRO 0NV5WaqNqmYxZo9LXmcCatRh16Brxaac5+Tu2RgtVGI8soDXz21jfG8qseKp3HdB42Hh 8ORmLHX70M9KiWXp2+BiUaH/GwQebntvapied6jYjF2dq3cUHhzD/CPp0hwkgs0KFO4p Fv7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=i7kcCf/ChL5MKBP/8dixAXherexlCxtTaQUgBqmxuRs=; b=FxG0waTc9TUcxK7+uSmg+rcv9kDc6Zbre/fXK9iM3P2uW5SJA85wwqbgndZpqfasVI R7odMswE0XM0+jVehfPAuFY0vRhDHmBW1s0kR0RRu5lF5IFPSUKmYDGyd+RURtexgCdB 5n1kCW2OZz2KXJH5nzgGeo78saARqJEaPcFn8ZvEqnDic5NgBUUbSiXjx5WC4rnqGTNB iTwc5IX97z7HyV6mFm6gTvjMfTfyLmfIjsm2Hz/7Rt4OipgjvAg9WzHaJJqzWQya0uzZ 8EZGG1JAwe6J2Vs8FrQ2E5rvcpQwlWshv2l/uroBHSXBl/BnaflVB0Z3m9uf42HSsvH5 Wiow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 129-v6si60536819pfy.164.2018.11.24.01.03.53; Sat, 24 Nov 2018 01:04:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727100AbeKXSZ2 (ORCPT + 99 others); Sat, 24 Nov 2018 13:25:28 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:14982 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726810AbeKXSZ2 (ORCPT ); Sat, 24 Nov 2018 13:25:28 -0500 Received: from fsav403.sakura.ne.jp (fsav403.sakura.ne.jp [133.242.250.102]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id wAO7btHD088370; Sat, 24 Nov 2018 16:37:55 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav403.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp); Sat, 24 Nov 2018 16:37:55 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id wAO7boAf088362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Nov 2018 16:37:55 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: Petr Mladek , Sergey Senozhatsky , Sergey Senozhatsky , Dmitriy Vyukov , Steven Rostedt , Linus Torvalds , Andrew Morton Cc: LKML , Tetsuo Handa Subject: [PATCH] printk: Add caller information to printk() output. Date: Sat, 24 Nov 2018 16:37:55 +0900 Message-Id: <1543045075-3008-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sometimes we want to print a whole line without being disturbed by concurrent printk() from interrupts and/or other threads, for printk() which does not end with '\n' can be disturbed. We tried to allow printk() callers to explicitly use their local buffer in order to make sure that a whole line is printed by one printk() call. But it turned out that it is not realistic to ask printk() callers to update their function arguments only for handling rare race conditions. Also, like Steven Rostedt mentioned at [1], buffering sometimes makes the situation worse. Therefore, we should not enforce buffering in a way that requires modification of printk() callers. I need to give up (at least for now) manipulating text which will be passed to printk(). Instead, I propose allow saving caller information as of calling log_store() and adding it as "T$thread_id" or "C$processor_id" upon printing each line of printk() output. Some examples for console output: [ 0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3) [ 0.299733] [T1] Performance Events: Haswell events, core PMU driver. [ 2.813808] [T35] clocksource: Switched to clocksource tsc [ 2.893984] [C0] random: fast init done Some examples for /dev/kmsg output: 6,21,0,-,from=T0;NX (Execute Disable) protection: active 6,22,0,-,from=T0;SMBIOS 2.7 present. 6,23,0,-,from=T0;DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 6,24,0,-,from=T0;tsc: Fast TSC calibration using PIT 6,25,0,-,from=T0;tsc: Detected 2793.552 MHz processor 7,26,858,-,from=T0;e820: update [mem 0x00000000-0x00000fff] usable ==> reserved 7,27,864,-,from=T0;e820: remove [mem 0x000a0000-0x000fffff] usable 6,28,882,-,from=T0;last_pfn = 0x140000 max_arch_pfn = 0x400000000 7,29,953,-,from=T0;MTRR default type: uncachable 6,512,753757,-,from=T1;PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug 6,513,757721,-,from=T1;ACPI: Enabled 4 GPEs in block 00 to 0F 6,514,984829,-,from=T1;ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) 6,515,985728,-,from=T1;acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] SUBSYSTEM=acpi DEVICE=+acpi:PNP0A03:00 6,516,987723,-,from=T1;acpi PNP0A03:00: _OSC: platform does not support [AER LTR] SUBSYSTEM=acpi DEVICE=+acpi:PNP0A03:00 6,517,989723,-,from=T1;acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] SUBSYSTEM=acpi DEVICE=+acpi:PNP0A03:00 5,1493,2893984,-,from=C0;random: fast init done [1] https://lkml.kernel.org/r/20181123105634.4956c255@vmware.local.home Signed-off-by: Tetsuo Handa --- kernel/printk/printk.c | 33 +++++++++++++++++++++++++++++++++ lib/Kconfig.debug | 17 +++++++++++++++++ 2 files changed, 50 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 5c2079d..5ace5ba 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -356,6 +356,9 @@ struct printk_log { u8 facility; /* syslog facility */ u8 flags:5; /* internal record flags */ u8 level:3; /* syslog level */ +#ifdef CONFIG_PRINTK_FROM + u32 from_id; /* thread id or processor id */ +#endif } #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS __packed __aligned(4) @@ -609,6 +612,12 @@ static int log_store(int facility, int level, /* fill message */ msg = (struct printk_log *)(log_buf + log_next_idx); +#ifdef CONFIG_PRINTK_FROM + if (in_task()) + msg->from_id = current->pid; + else + msg->from_id = 0x80000000 + raw_smp_processor_id(); +#endif memcpy(log_text(msg), text, text_len); msg->text_len = text_len; if (trunc_msg_len) { @@ -690,9 +699,17 @@ static ssize_t msg_print_ext_header(char *buf, size_t size, do_div(ts_usec, 1000); +#ifdef CONFIG_PRINTK_FROM + return scnprintf(buf, size, "%u,%llu,%llu,%c,from=%c%u;", + (msg->facility << 3) | msg->level, seq, ts_usec, + msg->flags & LOG_CONT ? 'c' : '-', + msg->from_id & 0x80000000 ? 'C' : 'T', + msg->from_id & ~0x80000000); +#else return scnprintf(buf, size, "%u,%llu,%llu,%c;", (msg->facility << 3) | msg->level, seq, ts_usec, msg->flags & LOG_CONT ? 'c' : '-'); +#endif } static ssize_t msg_print_ext_body(char *buf, size_t size, @@ -1037,6 +1054,9 @@ void log_buf_vmcoreinfo_setup(void) VMCOREINFO_OFFSET(printk_log, len); VMCOREINFO_OFFSET(printk_log, text_len); VMCOREINFO_OFFSET(printk_log, dict_len); +#ifdef CONFIG_PRINTK_FROM + VMCOREINFO_OFFSET(printk_log, from_id); +#endif } #endif @@ -1242,6 +1262,16 @@ static size_t print_time(u64 ts, char *buf) (unsigned long)ts, rem_nsec / 1000); } +#ifdef CONFIG_PRINTK_FROM +static size_t print_from(u32 id, char *buf) +{ + char tmp[16]; + + return sprintf(buf ? buf : tmp, "[%c%u] ", id & 0x80000000 ? 'C' : 'T', + id & ~0x80000000); +} +#endif + static size_t print_prefix(const struct printk_log *msg, bool syslog, char *buf) { size_t len = 0; @@ -1262,6 +1292,9 @@ static size_t print_prefix(const struct printk_log *msg, bool syslog, char *buf) } len += print_time(msg->ts_nsec, buf ? buf + len : NULL); +#ifdef CONFIG_PRINTK_FROM + len += print_from(msg->from_id, buf ? buf + len : NULL); +#endif return len; } diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 1af29b8..bf84fdc 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -17,6 +17,23 @@ config PRINTK_TIME The behavior is also controlled by the kernel command line parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst +config PRINTK_FROM + bool "Show caller information on printks" + depends on PRINTK + help + Selecting this option causes "thread id" (if in task context) or + "processor id" (if not in task context) of the printk() messages + to be added. + + This option is intended for environments where multiple threads + concurrently call printk() for many times, for it is difficult to + interpret without knowing where these lines (or sometimes individual + line which was divided into multiple lines due to race) came from. + + Since this is currently an experimental functionality which might be + changed/reverted in the future, there is no option to enable/disable + at the kernel command line parameter or sysfs interface. + config CONSOLE_LOGLEVEL_DEFAULT int "Default console loglevel (1-15)" range 1 15 -- 1.8.3.1