On Mon, Jun 24, 2019 at 09:10:15PM +0200, Jann Horn wrote: > That part of the documentation only talks about cases where you have a > control dependency on the return value of the refcount operation. But > refcount_inc() does not return a value, so this isn't relevant for > refcount_inc(). > > Also, AFAIU, the control dependency mentioned in the documentation has > to exist *in the caller* - it's just pointing out that if you write > code like the following, you have a control dependency between the > refcount operation and the write: > > if (refcount_inc_not_zero(&obj->refcount)) { > WRITE_ONCE(obj->x, y); > } > > For more information on the details of this stuff, try reading the > section "CONTROL DEPENDENCIES" of Documentation/memory-barriers.txt. IIRC the argument went as follows: - if you use refcount_inc(), you've already got a stable object and have ACQUIRED it otherwise, typically through locking. - if you use refcount_inc_not_zero(), you have a semi stable object (RCU), but you still need to ensure any changes to the object happen after acquiring a reference, and this is where the control dependency comes in as Jann already explained. Specifically, it would be bad to allow STOREs to happen before we know the refcount isn't 0, as that would be a UaF. Also see the comment in lib/refcount.c.