Received: by 10.223.185.116 with SMTP id b49csp825293wrg; Fri, 23 Feb 2018 07:23:23 -0800 (PST) X-Google-Smtp-Source: AH8x226MFfz2LnCV80D4jT60l2l2k0rb3hIYdRCjoqWXyEY5LPvPnaVVKiMdneJQbOehu4q/TK4Z X-Received: by 10.98.216.137 with SMTP id e131mr2151307pfg.17.1519399403592; Fri, 23 Feb 2018 07:23:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519399403; cv=none; d=google.com; s=arc-20160816; b=uItLTgpVpdGL9/aJDjFZkJ9nhp4dhHrYO8YFaf3upsUtWFwSEVG7YESxXFNjEh90Xa 90HOqd7MxxaQpA4ErypLv1ldBc0oG3OidozPwjMXu6IeoE4DCRn3WRMxeF07sc+Q+llv PMaEMJ/7US/IojLUyk2QSn88H6jebiMzwO+QcXpAN/iEf8udGDZKmioCTyVU5jUdy0J0 Z1ha44av0bX/BSf+iJ6TjxLZcLqzdLS2Rc+RZGaSvYP+qfzcHU2etgwkRWymkeODzJA3 JEm3AGpchx7XC+V8WJV76lMQq06ammZVFLIdSOmsLwlXc+XVzEJKJTbWSXHkrH9q/5N3 0aQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=rUJO4+Iidv8Xn6zQm7kycrF7FQGzHIlKrRJOsDFYBAY=; b=pYCXycH8uelWukV7Z4am8j5plhA4luyxYPMZo+tm03zU3PEHODWSY/P6GTEjQU22Ef QbAJwVGISuYcO5k/X5GZEGJFTJH9NNsdHllvON8+g67JsnrCIszjXMwAbfCf0vLOqqK4 /TVgFW9hwJnWHz1LArPeLgS4wQsC5jWY7FtEHkDpyGIQwOmtMJ14pQNN1PMS/3NzzYnm lH0BWuBEuXzFnNGakWS6UyxNoDq3wGaqDps6fx07pzxJRXOCMGqow4suFUcvdUxjbOlh LGdflpwwZbzbzeE5KPky+DHHriZH2XeD7BIyGyn1IelcBu5hCE2iV1HSk2lJuEUAjuBG KBuQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m7-v6si1942532pln.711.2018.02.23.07.23.07; Fri, 23 Feb 2018 07:23:23 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751834AbeBWPWH (ORCPT + 99 others); Fri, 23 Feb 2018 10:22:07 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35922 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751597AbeBWPWG (ORCPT ); Fri, 23 Feb 2018 10:22:06 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A22F6404085B; Fri, 23 Feb 2018 15:22:05 +0000 (UTC) Received: from treble (ovpn-121-149.rdu2.redhat.com [10.10.121.149]) by smtp.corp.redhat.com (Postfix) with SMTP id DBA1110AF9E3; Fri, 23 Feb 2018 15:22:04 +0000 (UTC) Date: Fri, 23 Feb 2018 09:22:04 -0600 From: Josh Poimboeuf To: Linus Torvalds Cc: Peter Zijlstra , Borislav Petkov , Ingo Molnar , Andy Lutomirski , X86 ML , LKML Subject: Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section Message-ID: <20180223152204.434g7mrvi6hjmmka@treble> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 23 Feb 2018 15:22:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 23 Feb 2018 15:22:05 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jpoimboe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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... -- Josh