On Tue, Jun 25, 2019 at 09:34:07AM +0200, Peter Zijlstra wrote: > 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. > Thanks a lot for the explanations and the pointers to the comment in lib/refcount.c . It makes it really clearly. Also, does this patch look good to you? If so and if ok with you, could you Ack it? The patch is not really "RFC" but I still tagged it as such since I wanted to have this discussion. Thanks! - Joel