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]

Date:   Thu, 28 May 2020 11:51:21 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     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 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

And yes, that 124 character line has a good reason for it. But that's
kind of the point. There are lots of perfectly fine reasons for longer
lines.

I'd much rather check for "no deep indentation" or "no unnecessarily
complex conditionals" or other issues that are more likely to be
_real_ problems.  But do we really have 80x25 terminals any more that
we'd care about?

               Linus