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] [day] [month] [year] [list]
Date:   Thu, 19 Nov 2020 16:20:08 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Chris Wilson <chris@...is-wilson.co.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Deadlock cpuctx_mutex / pmus_lock / &mm->mmap_lock#2

On Thu, Nov 19 2020 at 13:25, Chris Wilson wrote:
> Quoting Peter Zijlstra (2020-11-19 13:02:44)
>> 
>> Chris, I suspect this is due to i915 calling stop machine with all sorts
>> of locks held. Is there anything to be done about this? stop_machine()
>> is really nasty to begin with.
>> 
>> What problem is it typing to solve?
>
> If there is any concurrent access through a PCI bar (that is exported to
> userspace via mmap) as the GTT is updated, results in undefined HW
> behaviour (where that is not limited to users writing to other system
> pages).
>
> stop_machine() is the most foolproof method we know that works.

It's also the biggest hammer and is going to cause latencies just
because even on CPUs which are not involved at all. We have already
enough trouble vs. WBINVD latency wise, so no need to add yet another
way to hurt everyone.

As the gfx muck knows which processes have stuff mapped, there are
certainly ways to make them and only them rendevouz and do so while
staying preemptible otherwise. It might take an RESCHED_IPI to all CPUs
to achieve that, but that's a cheap operation compared to what you want
to do.

Thanks,

        tglx


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ