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]

Message-ID: <CAPM=9tw=NTZ-1NbGupgg42gOA1aFKZ2C6wt++q5BxaocaUbmFA@mail.gmail.com>
Date:   Mon, 15 Nov 2021 07:00:42 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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>,
        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 Sat, 13 Nov 2021 at 06:16, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

i915 will no longer be x86-64 only in theory, since Intel now produces
PCIe graphics cards using the same hw designs. These shouldn't AFAIK
require the same incoherent architecture, though PCIe unsnooped
transactions are a thing in the real world.

The thing is the same driver needs to build/work for the integrated
and discrete cards, hence this hack, but I'm sure someone can Intel
can do better.

I'll leave it to Daniel to figure out who/how.

Dave.