lkml.org 
[lkml]   [2023]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 08/12] s390: Replace cmpxchg_double() with cmpxchg128()
    On Tue, Jan 10, 2023 at 09:32:55AM +0100, Peter Zijlstra wrote:
    > On Tue, Jan 10, 2023 at 08:23:05AM +0100, Heiko Carstens wrote:
    >
    > > So, Alexander Gordeev reported that this code was already prior to your
    > > changes potentially broken with respect to missing READ_ONCE() within the
    > > cmpxchg_double() loops.
    >
    > Unless there's an early exit, that shouldn't matter. If you managed to
    > read garbage the cmpxchg itself will simply fail and the loop retries.

    I don't think that's true; without READ_ONCE() the compiler could (but is
    very unlikely to) read multiple times, and that could cause problems.

    For example:

    | prev = *ptr;
    |
    | do {
    | new = some_function_of(prev);
    | old = cmpxchg(ptr, prev, new);
    | } while (old != prev);

    Could effectively become:

    | prev1 = *ptr;
    | prev2 = *ptr;
    |
    | do {
    | new = some_function_of(prev1)
    | old = cmpxchg(ptr, prev2, new);
    | } while (old != prev2);

    ... which would effectively udpate from a stale value, throwing away prev2.
    That and the two generated reads could be in either order.

    So I do think it's warranted to use READ_ONCE() for the prev value feeding into
    a cmpxchg operation, even if that's only for the "once" part rather than lack
    of tearing.

    Thanks,
    Mark.

    \
     
     \ /
      Last update: 2023-03-26 23:34    [W:5.408 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site