From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753166AbdK1AP2 (ORCPT ); Mon, 27 Nov 2017 19:15:28 -0500 Received: from smtprelay0124.hostedemail.com ([216.40.44.124]:48803 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752665AbdK1AP0 (ORCPT ); Mon, 27 Nov 2017 19:15:26 -0500 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::,RULES_HIT:41:355:379:541:599:960:968:973:982:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1535:1544:1593:1594:1605:1711:1730:1747:1777:1792:2393:2553:2559:2562:2689:2693:2828:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4043:4321:4384:5007:6119:6691:7903:8660:10004:10848:11232:11658:11914:12043:12257:12296:12663:12679:12740:12760:12895:13095:13142:13148:13161:13229:13230:13255:13439:14659:14721:21063:21067:21080:21212:21324:21433:21627:30003:30012:30054:30070:30080:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: humor58_120c5badeef41 X-Filterd-Recvd-Size: 5958 Message-ID: <1511828121.32426.83.camel@perches.com> Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line From: Joe Perches To: Logan Gunthorpe , Julia Lawall Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Andy Whitcroft Date: Mon, 27 Nov 2017 16:15:21 -0800 In-Reply-To: <993ca1c1-6d27-2ee1-94ed-41e8249755bd@deltatee.com> References: <20171126054037.9743-1-logang@deltatee.com> <1511676085.20482.18.camel@perches.com> <5c0a2778-8e8f-9fbb-b13f-1d880acb949b@deltatee.com> <1511735382.20482.27.camel@perches.com> <355029d1-48f5-095e-0d99-bb726d2d56e5@deltatee.com> <86f3f594-79f7-c2ce-2cc6-f641bd6f55ae@deltatee.com> <1511771322.32426.1.camel@perches.com> <1511803686.32426.54.camel@perches.com> <322acd87-7708-cc90-c3d1-caad7bd023e5@deltatee.com> <1511804568.32426.56.camel@perches.com> <1511809027.32426.62.camel@perches.com> <993ca1c1-6d27-2ee1-94ed-41e8249755bd@deltatee.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.26.1-1 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 Mon, 2017-11-27 at 12:58 -0700, Logan Gunthorpe wrote: > > On 27/11/17 11:57 AM, Joe Perches wrote: > > It may or not be correct. > > It's absolutely not correct in that it either requires that a subsequent > KERN_CONT/pr_cont or a '\n' at the end and it has neither. The warning described is simply not correct. > > Without inter-function call code flow analysis, > > it's not possible to be correct. > > But how many cases actually have the pr_cont/KERN_cont called in > different functions? This appears to be exceedingly rare to me. Probably more than 50. > > If you can get the false positive & false negative > > rate higher, I'll listen. > The only two classes of false positives that you've pointed out or that > I'm aware of: > > 1) The case where call did not either end in a '\n' or have a > KERN_CONT/pr_cont in a subsequent call. or a bare printk. > I've been arguing (to deaf ears) wrong here too. > that a warning is appropriate here and this is not a false positive > because it absolutely is incorrect one way or the other. The checkpatch message itself has to be correct. Classifying the defect properly is a requirement. > Coccinnelle > will also suffer from this issue because it can no better decide whether > the developer intended for the next call to be a continuation or for a > '\n' to end the line. Well, coccinelle could do a better job than a line parser like checkpatch. Line parsing is what makes the type of defect difficult for a stupid parser, and checkpatch is one of those, to be correct enough with a low enough false positive rate to be useful. Please be aware I have already written just about exactly what you are trying to do more than once and discarded the work because the defect report rate was just too high. > 2) Cases where the pr_cont/KERN_CONT is not in sufficient context for > the script to detect. These are impossible to fix (and it's likely also > impossible for Coccinelle to be 100% accurate here). However, I'd expect > these to be *very* rare and I'm only actually aware of one case where > this has actually happened (lib/locking-selftest.c:1189) and (mostly by > luck) my v2 patch does not flag this where Coccinelle did. Not to > mention that continuation usage is discouraged in new code so this > should be even rarer on the majority of what checkpatch is used for. > > (also 3. would be the %pV case, but I've removed those in what could be > a v3 of the patch -- I'd also be happy to address other false positives > classes if I could find them) > False negatives are much harder to quantify or improve. But given that I > detect nearly 6000 errors No, you don't detect errors, you detect matches. If you look at your results a bit harder, you'll find many false positives. > And yet, you have not pointed out any false positives that my patch > gives which Coccinelle does/would not. It really feels to me like your > biases are guiding your decision here and you aren't really looking at > the results. I know the kernel source code style very well. You simply haven't looked very hard at your results. > Another thought I've had is that the dev_ functions don't have any form > of continuation. Untrue > So we could potentially limit checkpatch to looking for > those to avoid the issues with continuations. It's not high coverage but > at least a lot of the driver patches would be checked with no chance of > false positives. I think there would be value in doing that. For instance: drivers/mfd/ipaq-micro.c: dev_err(micro->dev, drivers/mfd/ipaq-micro.c- "unknown msg %d [%d] ", id, len); drivers/mfd/ipaq-micro.c- for (i = 0; i < len; ++i) drivers/mfd/ipaq-micro.c- pr_cont("0x%02x ", data[i]); drivers/mfd/ipaq-micro.c- pr_cont("\n"); $ git grep -A5 -P -w "\bdev_(warn|alert|crit|err|info|notice)" | \ grep -B5 -P -w "printk|pr_cont" will find some, but not all of these types of uses. $ grep -A5 -rP --include=*.[ch] '\bdev_(warn|alert|crit|err|info|notice).*\"[^"]+(? calls too.