linux-kernel - Re: Commit 25f12ae45fc1 ("maccess: rename probe_kernel_address to get_kernel

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 21 Jun 2020 12:44:19 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Kenneth R. Crudup" <kenny@...ix.com>
Cc:     Christoph Hellwig <hch@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Commit 25f12ae45fc1 ("maccess: rename probe_kernel_address to
 get_kernel_nofault") causing several OOPSes

On Sun, Jun 21, 2020 at 12:30 PM Kenneth R. Crudup <kenny@...ix.com> wrote:
>
> > Which is the obvious next step: would you mind compiling that file
> > with and without the patch and sending me the two object files?
>
> It looks like you had already, do you still need me to do this?

Yes please. For me that patch makes no difference. With gcc, it
generates the exact same code.

> FWIW, here's my gcc info:
>
> $  gcc --version
> gcc (Ubuntu 9.3.0-13ubuntu1) 9.3.0

Yeah, well, I've got

  gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)

but it's not like yours is any known problematic one.

But please compile that probe_roms file with Chrisptoph's patch that
makes things work for you, and without it - but otherwise identically
and with the same config options that work with that patch applied.

> OH- I did change arch/x86/Makefile in my own builds- maybe this could matter?

Doubtful, but who knows. The fact that so far yours seems to be the
only report of this, and it looks inexplicable, maybe it has that
tuning difference that triggers it.

But don't change it now. If it is what triggers the issue, it's still
an interesting datapoint.

You might test (separately) if removing that change from your build
makes a difference, but I'd like to see what the code generation
difference is with the patch and without, since there _shouldn't_ be
any.

          Linus