lkml.org 
[lkml]   [2019]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/18] locking/atomic: atomic64 type cleanup
    Hi Mark,

    On Wed, May 22, 2019 at 02:22:32PM +0100, Mark Rutland wrote:
    > Currently architectures return inconsistent types for atomic64 ops. Some return
    > long (e..g. powerpc), some return long long (e.g. arc), and some return s64
    > (e.g. x86).

    (only partially related, but probably worth asking:)

    While reading the series, I realized that the following expression:

    atomic64_t v;
    ...
    typeof(v.counter) my_val = atomic64_set(&v, VAL);

    is a valid expression on some architectures (in part., on architectures
    which #define atomic64_set() to WRITE_ONCE()) but is invalid on others.
    (This is due to the fact that WRITE_ONCE() can be used as an rvalue in
    the above assignment; TBH, I ignore the reasons for having such rvalue?)

    IIUC, similar considerations hold for atomic_set().

    The question is whether this is a known/"expected" inconsistency in the
    implementation of atomic64_set() or if this would also need to be fixed
    /addressed (say in a different patchset)?

    Thanks,
    Andrea

    \
     
     \ /
      Last update: 2019-05-23 10:31    [W:2.850 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site