Received: by 10.223.185.116 with SMTP id b49csp1118248wrg; Fri, 23 Feb 2018 12:14:26 -0800 (PST) X-Google-Smtp-Source: AH8x224TKdsejAcN8GGM5fRtZ3gsMJLz7PeM6zVgHqHW1eYpVyltFJflsBc9IC6WbdCpbqwnaWMp X-Received: by 2002:a17:902:10d:: with SMTP id 13-v6mr2736460plb.266.1519416866291; Fri, 23 Feb 2018 12:14:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519416866; cv=none; d=google.com; s=arc-20160816; b=bxQw0Xl9sT3q329razMEGEtim53zWBP2q6g24nMATQk9X44mFYDP3AkQWiRA4JdFdS AGtBlgTCSyniqb3t6lWc6fumfgtnVP655k2kPDy0HBITftYhTdIna41ETMIjcD8XzxBE 92u7HmwQ45fGHoi4KHMvbtQDf627WTO+gPMiRtQa2VmLV6dgsBdweVh7O/8SyFIFGZZd YoV6eg4ChcrrPJugBWSDhhYecs/UgxaURbdYwcmNPM8u5iWmmA6DHkA25NiFZvGP9STH 1oNHAAUv2UjLVolyXqOiBd7ifj0fHlTxcWTnxlTUQIIrSP6OJW24SMl29kgov3uaX8r8 nVDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=U24B6MSbqXBJs5KMmVsLdDpATWSfzjI/KzeACujMDpQ=; b=ONGy4pLI7Secr0Oi/dv1mvW/y2TJfUnh5IhFLAFVP8NV0ySquTwSUQpmLKr/2LDicV pWpO+XicDvhkPvuIVbdYwTp5v8z41peIsMfXihUBTa7k26u7QL1IEmi833SNKLjjucNK lvnrqWcyIRyYtyRHBg7suOfYB6vrFOrRbzQareJ3s3KhcahgqzceL6AXtny95nvj2o79 Dsw0PmaXpQL9fuvNZTI0RxaAEtp5iuCSyM7F0V6oBaNpf4FzY+hHMT3J/JAc2cAYhm45 RbWOhXc5fF3fI1qkTgQIihE9Nw68P+AvFmC+eurcghK9PcsQwD/95des5HWz+pIQq1jf ZS/w== 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 t132si1912551pgc.238.2018.02.23.12.14.11; Fri, 23 Feb 2018 12:14:26 -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 S1754978AbeBWUNU (ORCPT + 99 others); Fri, 23 Feb 2018 15:13:20 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:33965 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754543AbeBWUNR (ORCPT ); Fri, 23 Feb 2018 15:13:17 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1epJiV-0005k6-V2; Fri, 23 Feb 2018 13:13:16 -0700 Received: from 174-19-85-160.omah.qwest.net ([174.19.85.160] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1epJiU-0000nG-R4; Fri, 23 Feb 2018 13:13:15 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Josh Poimboeuf Cc: Linus Torvalds , Peter Zijlstra , Borislav Petkov , Ingo Molnar , Andy Lutomirski , X86 ML , LKML References: <20180219202826.19797-1-bp@alien8.de> <20180220192956.si2a6m3ckskexvte@treble> <20180220204435.GC24320@pd.tnic> <20180221091553.gxnvhbitiewo2mjc@gmail.com> <20180221175429.GC9989@pd.tnic> <20180222092327.GM25201@hirez.programming.kicks-ass.net> <20180223152204.434g7mrvi6hjmmka@treble> Date: Fri, 23 Feb 2018 14:12:46 -0600 In-Reply-To: <20180223152204.434g7mrvi6hjmmka@treble> (Josh Poimboeuf's message of "Fri, 23 Feb 2018 09:22:04 -0600") Message-ID: <87woz331oh.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1epJiU-0000nG-R4;;;mid=<87woz331oh.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=174.19.85.160;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+xpv4Th3ZPwwM4S2Mf2Wwpp/XvmsVWuOU= X-SA-Exim-Connect-IP: 174.19.85.160 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa04.xmission.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG,T_XMDrugObfuBody_08, XMNoVowels,XMSubLong autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4988] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Josh Poimboeuf X-Spam-Relay-Country: X-Spam-Timing: total 293 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.6 (1.2%), b_tie_ro: 2.5 (0.8%), parse: 1.11 (0.4%), extract_message_metadata: 5 (1.7%), get_uri_detail_list: 2.9 (1.0%), tests_pri_-1000: 5 (1.7%), tests_pri_-950: 1.47 (0.5%), tests_pri_-900: 1.28 (0.4%), tests_pri_-400: 30 (10.3%), check_bayes: 29 (9.8%), b_tokenize: 10 (3.5%), b_tok_get_all: 9 (3.2%), b_comp_prob: 3.7 (1.3%), b_tok_touch_all: 2.7 (0.9%), b_finish: 0.69 (0.2%), tests_pri_0: 228 (77.6%), check_dkim_signature: 0.64 (0.2%), check_dkim_adsp: 2.9 (1.0%), tests_pri_500: 8 (2.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Josh Poimboeuf writes: > On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote: >> So what we could perhaps do is: >> >> - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG >> >> - make sure the *default* loglevel be LOGLEVEL_WARNING >> >> - now you can use pr_debug() in the oops code to print messages to >> the log, but they won't be printed to the screen. >> >> And people who really want everything can still set a loglevel that is >> much higher, because "console_verbose" would only do that "at least" >> thing. >> >> That would seem like the best of both worlds, no? > > Maybe. > > Broadly speaking, I think our goal should be, in the worst case, to try > to ensure that the essential data is captured. > > But the definitions of "worst case" and "essential data" can vary a lot, > depending on both the user's setup and the nature of the bug. We're not > going to be able to get it right 100% of the time. > > You're assuming the worst case of > > "an 80x25 screen is the only interface to the console". > > But there's another worst case of > > "we had unlimited serial port logging, but didn't dump enough data". > > With your proposal, the latter might instead become: > > "we had unlimited serial port logging, but didn't dump enough data > because the default loglevel was too low." > > I did a little analysis of panics reported on lkml via .jpg files > (either attached or in a URL). In the last two years I only found 11 > such reports. (And only two of them were 25x80, the rest were at least > 47 rows.) > > On the other hand, I found a *ton* of panics which were copy/pasted. It > was way too many to count, but a rough guess is about one per day. > > So ~1.5% of bugs are reported via cell phone camera (with only about > 5-10% of *those* on a tiny 25x80 screen, with the rest having at least > 47 rows). > > It's not very scientific, but it gives a general idea, I think. The > cell phone camera thing has become a pretty rare way to report bugs, and > with the proliferation of virtualization and automated testing I would > expect that trend to continue. > > So my worry with your proposal is that many (or most?) people won't > change their default log level to DEBUG, and then all these nice > additional bits of data we're adding won't ever get printed, making > debug harder for the ~98.5% case of sane serial port logging. > > But then again, I don't have any better ideas... Please also note there are serial ports and there are serials ports. There are serial ports on virtual machines that don't have a speed. Then there are serial ports on physical hardware some at 9600 baud, and in all cases they are slow. So on a physical serial port tersness is a virtue (unless the machine is completely dead). Then we have panics and the like that are reported by kdump. Those should be cut and pastable as well. But require that someone has done the work to set that up so that is a reliable path. I know that in working on kexec-on-panic what I have found is the less code in a critical path you have to run in a b0rken kernel the higher your chance of that code running successfully. I expect that applies to the panic printer as much as anything else. Eric