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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Jul 2009 09:42:14 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org
Subject: Re: [RFC PATCH 1/3] kmemleak: Allow partial freeing of memory blocks

Pekka Enberg <penberg@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/