On Tue, Mar 16, 2021 at 11:03:05AM -0700, Davidlohr Bueso wrote:
> On Tue, 16 Mar 2021, Peter Zijlstra wrote:
> >
> > IIRC we made the explicit choice to never loop here. That saves having
> > to worry about getting stuck in in-kernel loops.
> >
> > Userspace triggering the case where the futex
On Tue, Mar 16 2021 at 11:03, Davidlohr Bueso wrote:
> On Tue, 16 Mar 2021, Peter Zijlstra wrote:
>>IIRC we made the explicit choice to never loop here. That saves having
>>to worry about getting stuck in in-kernel loops.
>>
>>Userspace triggering the case where the futex goes corrupt is UB, after
On Tue, 16 Mar 2021, Peter Zijlstra wrote:
IIRC we made the explicit choice to never loop here. That saves having
to worry about getting stuck in in-kernel loops.
Userspace triggering the case where the futex goes corrupt is UB, after
that we have no obligation for anything to still work. It's
On Sun, Mar 14, 2021 at 10:02:24PM -0700, Davidlohr Bueso wrote:
> Before 34b1a1ce145 (futex: Handle faults correctly for PI futexes) any
> concurrent pi_state->owner fixup would assume that the task that fixed
> things on our behalf also correctly updated the userspace value. This
> is not always
Before 34b1a1ce145 (futex: Handle faults correctly for PI futexes) any
concurrent pi_state->owner fixup would assume that the task that fixed
things on our behalf also correctly updated the userspace value. This
is not always the case anymore, and can result in scenarios where a lock
stealer
5 matches
Mail list logo
