Messages in this thread | | | Date | Mon, 13 Mar 2006 07:40:48 +0100 | From | Nick Piggin <> | Subject | Re: [patch 1/3] radix tree: RCU lockless read-side |
| |
On Mon, Mar 13, 2006 at 08:34:53AM +0530, Balbir Singh wrote: > On 3/11/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > Balbir Singh wrote: > > > <snip> > > > > > >> if (slot->slots[i]) { > > >>- results[nr_found++] = slot->slots[i]; > > >>+ results[nr_found++] = &slot->slots[i]; > > >> if (nr_found == max_items) > > >> goto out; > > >> } > > > > > > > > > A quick clarification - Shouldn't accesses to slot->slots[i] above be > > > protected using rcu_derefence()? > > > > > > > I think we're safe here -- this is the _address_ of the pointer. > > However, when dereferencing this address in _gang_lookup, > > I think we do need rcu_dereference indeed. > > > > Yes, I saw the address operator, but we still derefence "slots" to get > the address. >
OK, I reread what you wrote and I misunderstood you earlier I guess. slot->slots[i] does dereference the pointer at the ith entry of slots, but &slot->slots[i] does not, it will return the same thing as slot->slots+i, which only dereferences 'slot' (which we've established to be safe).
Even if &slot->slots[i] did, for some silly compiler, dereference the pointer, we never actually see it or use it so it should be harmless.
Nick
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |