Re: kmemcheck caught read from freed memory (cfq_free_io_context)

On Wed, 2008-04-02 at 13:20 +0200, Peter Zijlstra wrote:
On Wed, 2008-04-02 at 13:14 +0200, Jens Axboe wrote:
On Wed, Apr 02 2008, Peter Zijlstra wrote:
On Wed, 2008-04-02 at 13:07 +0200, Jens Axboe wrote:
On Wed, Apr 02 2008, Pekka Enberg wrote:
Hi Paul,

On Wed, Apr 2, 2008 at 1:55 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
I will check this when I get back to some bandwidth -- but in the meantime,
does kmemcheck special-case SLAB_DESTROY_BY_RCU? It is legal to access
newly-freed items in that case, as long as you did rcu_read_lock()
before gaining a reference to them and don't hold the reference past
the matching rcu_read_unlock().

No, kmemcheck is work in progress and does not know about
SLAB_DESTROY_BY_RCU yet. The reason I asked Vegard to post the warning
was because Peter, Vegard, and myself identified this particular
warning as a real problem. But yeah, kmemcheck can cause false
positives for RCU for now.

Makes sense, and to me Pauls analysis of the code looks totally correct
- there's no bug there, at least related to hlist traversal and
kmem_cache_free(), since we are under rcu_read_lock() and thus hold off
the grace for freeing.

but what holds off the slab allocator re-issueing that same object and
someone else writing other stuff into it?

Nothing, that's how rcu destry works here. But for the validation to be
WRONG radix_tree_lookup(..., old_key) must return cic for new_key, not
NULL.



A B C

cfq_cic_lookup(cfqd_1, ioc)

rcu_read_lock()
cic = radix_tree_lookup(, cfqd_q);

cfq_cic_free()

cfq_cic_link(cfqd_2, ioc,)

rcu_read_unlock()


and now we have that:

cic->key == cfqd_2


I'm not seeing anything stopping this from happening.

Which is also why we need hlist_for_each_safe_rcu() because as soon as
we kfree()d the thing, someone else might get the object and start
poking at the hlist pointers, wrecking out iteration.

Or worse, when C doesn't happen and B free's the very last object and
the slab does get returned, any usage of cic after rcu_read_unlock()
might poke into free memory.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages