linux-kernel - Re: [GIT pull - RFC] locking/kcsan for v5.8

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:   Mon, 8 Jun 2020 16:11:06 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Marco Elver <elver@...gle.com>
Subject: Re: [GIT pull - RFC] locking/kcsan for v5.8

On Tue, Jun 2, 2020 at 6:07 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> please consider to pull the latest locking/kcsan branch from:

Gaah. So I left this until I had cleared out my queues, and now that I
start looking at it, I find myself more annoyed by the messy history
than by the kcsan code.

For example, it generates conflicts with the sparc tree, because the
sparc page table changes weren't done as a shared branch, but
duplicated as commits (and the subsequent changes cause some
conflicts).

And the read-once/write-once changes that I was aware of and approve
of, are similarly mixed in here randomly, rather than being as a
branch of their own. I see that Will then made his own branch, but
then we'd have the same issue as with the sparc changes.

The things I was _expecting_ to find annoying (various random changes
to random code due to kcsan reports), I don't actually see.

Instead I see odd small completely unrelated things like the
x86/purgatory changes that were merged in for odd reasons.

How painful would it be to sort this out properly? I'll happily take
the read-once changes as a separate branch, for example. There's
nothing really controversial there., even if the gcc version bump
might annoy some (I personally think we could bump it further up to
4.9, and require _Generic, for example - I suspect we have a number of
places that could use _Generic instead of nasty sizeof games).

I'd even make an exception and say "ok, just rebase the kcsan stuff on
top" to clean up the messy history, because this is the kind of new
feature that shouldn't affect a normal build, and I'd hate to have
other changes that _can_ affect a normal build - like those atomic
changes - mixed up in the middle of the kcsan stuff.

So my first reaction from looking at this is that I'd rather get the
infrastructure separately (like I already got the sparc32 page table
changes), so that once I _do_ get the kcsan bits, they really would be
"this introduces no semantic changes what-so-ever when not enabled".

IOW, I'd be inclined to instead pull Will's branch, and then whatever
x86 entry branches, and then kcsan last with _just_ kcsan stuff.

Will that make everybody else cry tears of frustration?

               Linus