Messages in this thread | | | Date | Thu, 3 Apr 2008 14:27:53 -0700 | From | "Paul E. McKenney" <> | Subject | Re: kmemcheck caught read from freed memory (cfq_free_io_context) |
| |
On Thu, Apr 03, 2008 at 10:49:23PM +0300, Pekka J Enberg wrote: > Hi Paul, > > On Thu, 3 Apr 2008, Paul E. McKenney wrote: > > OK, so another approach would be to use a larger shadow block for > > SLAB_DESTROY_BY_RCU slabs, so that each shadow location would have enough > > room for an rcu_head and a size in addition to the flag. That would > > trivialize tracking, or, more accurately, delegate such tracking to the > > RCU infrastructure. > > Yeah, or just allocate some extra spaces for the RCU case and not > overload the current shadow pages. But sounds good to me.
As long as we have an rcu_head for each memory block in the slab, I am not to worried about where they are allocated.
> On Thu, 3 Apr 2008, Paul E. McKenney wrote: > > Of course, the case where the block gets reallocated before the RCU > > grace period ends would also need to be handled (which my rough sketch > > yesterday did -not- handle, by the way...). > > > > There are a couple of ways of doing this. Probably the easiest approach > > is to add more state to the flag, so that the RCU callback would check > > to see if reallocation had already happened. If so, it would update the > > state to indicate that the rcu_head was again available, and would need to > > repost itself if the block had been freed again after being reallocated. > > > > The other approach would be to defer actually adding the block to the > > freelist until the grace period expired. This would be more accurate, > > but also quite a bit more intrusive. > > We already talked about deferring the actual freeing in kmemcheck to > better detect these use-after-free conditions with Vegard. So it's > something that we probably want to do regardless of RCU.
Then it is especially important that the rcu_head be pre-allocated. Otherwise we could get into out-of-memory deadlocks where a free operation is blocked by an allocation operation. ;-)
Thanx, Paul
| |