linux-kernel - Re: clean up kernel_{read,write} & friends v2

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: <7934ff03b72eac71a8cff3e8bd0f4d8cac0e136e.camel@perches.com>
Date:   Thu, 28 May 2020 14:03:57 -0700
From:   Joe Perches <joe@...ches.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>
Cc:     Al Viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
        David Howells <dhowells@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        NetFilter <netfilter-devel@...r.kernel.org>
Subject: Re: clean up kernel_{read,write} & friends v2

On Thu, 2020-05-28 at 12:22 -0700, Joe Perches wrote:
> On Thu, 2020-05-28 at 11:51 -0700, Linus Torvalds wrote:
> > On Wed, May 27, 2020 at 10:40 PM Christoph Hellwig <hch@....de> wrote:
> > > this series fixes a few issues and cleans up the helpers that read from
> > > or write to kernel space buffers, and ensures that we don't change the
> > > address limit if we are using the ->read_iter and ->write_iter methods
> > > that don't need the changed address limit.
> > 
> > Apart from the "please don't mix irrelevant whitespace changes with
> > other changes" comment, this looks fine to me.
> > 
> > And a rant related to that change: I'm really inclined to remove the
> > checkpatch check for 80 columns entirely, but it shouldn't have been
> > triggering for old lines even now.
> > 
> > Or maybe make it check for something more reasonable, like 100 characters.
> > 
> > I find it ironic and annoying how "checkpatch" warns about that silly
> > legacy limit, when checkpatch itself then on the very next few lines
> > has a line that is 124 columns wide

Another option is to only warn by default when a line in a
patch but not a file exceeds the line length maximum.
---
 scripts/checkpatch.pl | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd750241958b..78f5b7f97e42 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3282,8 +3282,10 @@ sub process {
 
 			if ($msg_type ne "" &&
 			    (show_type("LONG_LINE") || show_type($msg_type))) {
-				WARN($msg_type,
-				     "line over $max_line_length characters\n" . $herecurr);
+				my $msg_level = \&WARN;
+				$msg_level = \&CHK if ($file);
+				&{$msg_level}($msg_type,
+					      "line over $max_line_length characters\n" . $herecurr);
 			}
 		}