linux-kernel - Re: [git pull] drm fixes + one missed next for 5.16-rc1

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:   Fri, 12 Nov 2021 12:16:19 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dave Airlie <airlied@...il.com>,
        Matthew Auld <matthew.auld@...el.com>,
        Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>,
        Ashutosh Dixit <ashutosh.dixit@...el.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm fixes + one missed next for 5.16-rc1

On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie <airlied@...il.com> wrote:
>
> I missed a drm-misc-next pull for the main pull last week. It wasn't
> that major and isn't the bulk of this at all. This has a bunch of
> fixes all over, a lot for amdgpu and i915.

Ugh.

The i915 conflict was trivial, but made me aware of that absolutely
disgusting "wbinvd_on_all_cpus()" hack.

And that thing is much too ugly to survive. I made my merge resolution
remove that disgusting thing.

That driver is x86-only anyway, so it all seemed completely bogus in
the first place.

And if there is some actual non-x86 work in progress for i915, then
that wbinvd_on_all_cpus() needs to be replaced with something proper
and architecture-neutral anyway, most definitely involving a name
change, and almost certainly also involving a range for the cache
writeback.

Because that "create broken macro on other architectures" thing is
*NOT* acceptable.

And I sincerely hope to the gods that no cache-incoherent i915 mess
ever makes it out of the x86 world. Incoherent IO was always a
historical mistake and should never ever happen again, so we should
not spread that horrific pattern around.

                Linus