Re: [RFC PATCH 1/3] kmemleak: Allow partial freeing of memory blocks

Catalin Marinas
2009-07-07T07:59:23Z

Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> On Mon, 2009-07-06 at 11:51 +0100, Catalin Marinas wrote:
>> @@ -552,8 +558,29 @@ static void delete_object(unsigned long ptr)
>> */
>> spin_lock_irqsave(&object->lock, flags);
>> object->flags &= ~OBJECT_ALLOCATED;
>> + start = object->pointer;
>> + end = object->pointer + object->size;
>> + min_count = object->min_count;
>> spin_unlock_irqrestore(&object->lock, flags);
>> put_object(object);
>> +
>> + if (!size)
>> + return;
>> +
>> + /*
>> + * Partial freeing. Just create one or two objects that may result
>> + * from the memory block split.
>> + */
>> + if (in_atomic())
>> + gfp_flags = GFP_ATOMIC;
>> + else
>> + gfp_flags = GFP_KERNEL;
>
> Are you sure we can do this? There's a big fat comment on top of
> in_atomic() that suggest this is not safe.

It's not safe but I thought it's slightly better than not checking it.

> Why do we need to create the
> object here anyway and not in the _alloc_ paths where gfp flags are
> explicitly passed?

That's the free_bootmem case where Linux can only partially free a
block previously allocated with alloc_bootmem (that's why I haven't
tracked this from the beginning). So if it only frees some part in the
middle of a block, I would have to create two separate
kmemleak_objects (well, I can reuse one but I preferred fewer
modifications as this is not on a fast path anyway).

In the tests I did, free_bootmem is called before the slab allocator
is initialised and therefore before kmemleak is initialised, which
means that the requests are just logged and the kmemleak_* functions
are called later from the kmemleak_init() function. All allocations
via this function are fine to only use GFP_KERNEL.

If my reasoning above is correct, I'll only pass GFP_KERNEL and add a
comment in the code clarifying when the partial freeing happen.

Thanks.

--
Catalin