linux-kernel - Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ddea7e4-24bd-eadc-18ff-ab5aa5d81e58@deltatee.com>
Date:   Mon, 27 Nov 2017 15:56:57 -0700
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Julia Lawall <julia.lawall@...6.fr>
Cc:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org, Andy Whitcroft <apw@...onical.com>
Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't
 end in a new line

On 27/11/17 01:49 PM, Julia Lawall wrote:
> Perhaps if there is a possible flow from one print to another within a
> single function and in both cases the format string is at least say 25
> characters (completely random value), then it is pretty likely that a
> newline is intended.

This is on the edge of what I think could be done with checkpatch. I did 
a quick look through some of the cases I've noticed and haven't found 
any that this wouldn't pass. I'm not sure how you'd pick an appropriate 
threshold though. I do think it's quite clever, though.

> Alternatively, if the first format string doesn't end in a space and the
> second one doesn't begin with a space, then a newline is also likely
> intended.

This makes more sense to me but I don't expect it to be 100% accurate 
either. See, for example, drivers/char/dtlk.c:640 which has no space in 
either printk. You could maybe expand the rule to include ':' and '(' as 
the last character.

Logan