Re: [PATCH net-next 1/3] net: ipv4: fix potential memory leak by assigning uhash_entries

[Paul Gortmaker <paul.gortmaker@windriver.com>]

On 11-06-22 01:04 AM, Eric Dumazet wrote:
> Le mardi 21 juin 2011 à 16:43 -0400, Paul Gortmaker a écrit :

[...]

>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index abca870..6f53a5a 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -2155,7 +2155,7 @@ void udp4_proc_exit(void)
>>  }
>>  #endif /* CONFIG_PROC_FS */
>>  
>> -static __initdata unsigned long uhash_entries;
>> +static __initdata unsigned long uhash_entries = UDP_HTABLE_SIZE_MIN;
>>  static int __init set_uhash_entries(char *str)
>>  {
>>  	if (!str)
> 
> Arg no, I really wanted to get more hash slots in my 32bit machines,
> with 4Gbytes of memory.
> 
> Here is what I currently have (without your patch)
> 
> [    1.903086] UDP hash table entries: 512 (order: 2, 16384 bytes)
> 
> 
> I mean, this kmemleak was already reported.

Ah, I'd not read that thread - here is the link if anyone else
is following along:

http://lists-archives.org/linux-kernel/27460513-kmemleak-for-mips.html

> 
> 32MB machines are things of the past.
> 
> If you really care, please add a change to alloc_large_system_hash() ?

Given the user list (dcache.c, inode.c, pid.c, ...) it probably
isn't worth the churn of adding a min argument to the calls.
I'm fine with dropping this patch (and glad I'd CC'd you on it)

Thanks,
Paul.

> 
> 
>