Re: [PATCH 2/3] mn88472: make sure the private data struct is nulled after free

[Hans Verkuil <hverkuil@xs4all.nl>]

On 12/06/2014 09:26 PM, Benjamin Larsson wrote:
> On 12/06/2014 07:37 PM, Antti Palosaari wrote:
>>>
>>> I do think it is good practice to set pointers to null generally as that
>>> would have saved me several days of work of whentracking down this bug.
>>> The current dvb framework contain several other cases where pointers are
>>> feed'd but not nulled.
>>
>> There is kzfree() for that, but still I am very unsure should we start 
>> zeroing memory upon release driver has allocated, or just relase it 
>> using kfree.
>>
>> regards
>> Antti 
> 
> Well I guess I am biased as I have spent lots of time finding a bug that 
> probably wouldn't exist if the policy was that drivers always should set 
> their memory to zero before it is free'd.

Just because you zero memory before it is freed doesn't mean it stays zeroed.
As soon as it is freed some other process might take that memory and fill it
up again. So zeroing is pointless and in fact will only *hide* bugs.

The only reason I know of for zeroing memory before freeing is if that memory
contains sensitive information and you want to make sure it is gone from memory.

You can turn on the kmemcheck kernel option when compiling the kernel to test
for accesses to uninitialized memory if you suspect you have a bug in that
area.

Anyway:

Nacked-by: Hans Verkuil <hans.verkuil@cisco.com>

Regards,

	Hans

> Maybe we should have a compile 
> time override so that all free calls zeroes the memory before the actual 
> free? Maybe there already is this kind of feature?
> 
> MvH
> Benjamin Larsson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>