From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756665AbcJWTGw (ORCPT ); Sun, 23 Oct 2016 15:06:52 -0400 Received: from smtprelay0106.hostedemail.com ([216.40.44.106]:51731 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754123AbcJWTGv (ORCPT ); Sun, 23 Oct 2016 15:06:51 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2194:2198:2199:2200:2393:2553:2559:2562:2828:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:4321:4470:5007:6117:6691:7903:8792:9108:10004:10400:10848:11232:11658:11914:12219:12294:12296:12740:12760:13439:13618:14181:14659:14721:21080:21324:21433:30006:30054:30060:30074:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: step25_5888e069dfb31 X-Filterd-Recvd-Size: 3178 Message-ID: <1477249607.3561.2.camel@perches.com> Subject: Re: linux.git: printk() problem From: Joe Perches To: Linus Torvalds , Geert Uytterhoeven Cc: Tetsuo Handa , Linux Kernel Mailing List , Sergey Senozhatsky , Petr Mladek Date: Sun, 23 Oct 2016 12:06:47 -0700 In-Reply-To: References: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.22.0-2ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote: > On Sun, Oct 23, 2016 at 2:22 AM, Geert Uytterhoeven > wrote: > > > > These changes have an interesting side-effect on sequences of printk()s that > > lack proper continuation: they introduced a discrepancy between dmesg output > > and the actual kernel output. > > Yes. > > So the "print vs log" handling is really really horrible. I cleaned up > some of it, but left the really fundamental problems. I wanted to just > rewrite it all, but didn't quite have the heart for it. > > The best solution by far would be to just not support KERN_CONT at > all, but there's too many "silly details" things that keep it from > being possible. > > The basic issue is that we have the line buffer that is used for > continuations, and then the record buffer that is used for logging. > > And those two per se sound fairly easy to handle ("KERN_CONT means > append to the line buffer, otherwise flush the line buffer and move to > the record buffer"). > > But what complicates things more is then the "console output", which > has two issues: > > - it is done outside the locking regime for the line buffer and the > record buffer. > > - it is done on _partial_ line buffers. EOL KERN_ and thread interleaving still exists. > It would be really quite easy to say "we don't print out > continuation lines immediately, we just buffer them for 0.1s instead, > and KERN_CONT only works for things that really happen more or less > immediately". Or use to a start/stop buffer (maybe via KERN_ and \n) with PID/TIDs added to /dev/kmsg and that short-term timer to reassemble. > Maybe that really is the right answer. Because the original cause of > us having to bend over backwards in this case is really no longer > there. And it would simplify printk a *lot*. A timer might be a good idea, but perhaps Sergey and Petr might have some interest in that too. (added to cc's)