linux-kernel - Re: cleanup the walk_page

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:   Sat, 17 Aug 2019 00:37:49 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        David Howells <dhowells@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Christoph Hellwig <hch@...radead.org>,
        Thomas Hellström <thomas@...pmail.org>,
        Jerome Glisse <jglisse@...hat.com>,
        Steven Price <steven.price@....com>,
        Linux-MM <linux-mm@...ck.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Minchan Kim <minchan@...nel.org>
Subject: Re: cleanup the walk_page_range interface

On Fri, Aug 16, 2019 at 11:41 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> I certainly prefer that method of API change :-)
> (see the current "keys: Replace uid/gid/perm permissions checking with
> an ACL" in linux-next

Side note: I will *not* be pulling that again.

It was broken last time, and without more people reviewing the code,
I' m not pulling it for 5.4 either even if David has an additional
commit on top that might have fixed the original problem.

There's still a pending kernel test report on commit f771fde82051
("keys: Simplify key description management") from another of David's
pulls for 5.3 - one that didn't get reverted.

David, look in your inbox for a kernel test report about

  kernel BUG at security/keys/keyring.c:1245!

(It's the

        BUG_ON(index_key->desc_len == 0);

line - the line numbers have since changed, and it's line 1304 in the
current tree).

I'm not sure why _that_ BUG_ON() now triggers, but I wonder if it's
because 'desc_len' went from a 'size_t' to an 'u8', and now a desc_len
of 256 is 0. Or something. The point being that there have been too
many bugs in the pulls and nobody but David apparently ever had
anything to do with any of the development. This code needs more eyes,
not more random changes.

So I won't be compounding on that workflow problem next merge window.

                  Linus