[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YG3hcg32xw/D03P2@hirez.programming.kicks-ass.net>
Date: Wed, 7 Apr 2021 18:44:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Christoph Müllner <christophm30@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>, Guo Ren <guoren@...nel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-csky@...r.kernel.org,
linux-arch <linux-arch@...r.kernel.org>,
Guo Ren <guoren@...ux.alibaba.com>,
Will Deacon <will@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Waiman Long <longman@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Anup Patel <anup@...infault.org>
Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
ARCH_USE_QUEUED_SPINLOCKS_XCHG32
On Wed, Apr 07, 2021 at 05:51:07PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> > Further, it is not the case that RISC-V has no guarantees at all.
> > It just does not provide a forward progress guarantee for a
> > synchronization implementation,
> > that writes in an endless loop to a memory location while trying to
> > complete an LL/SC
> > loop on the same memory location at the same time.
>
> Userspace can DoS the kernel that way, see futex.
The longer answer is that this means you cannot share locks (or any
atomic really) across a trust boundary, which is of course exactly what
futex does.
Powered by blists - more mailing lists