linux-kernel - Re: [PATCH 1/2] mm: Introduce GFP_PANIC for early-boot allocations

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090509093101.GC13784@elte.hu>
Date:	Sat, 9 May 2009 11:31:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, gorcunov@...nvz.org,
	kosaki.motohiro@...fujitsu.com, mel@....ul.ie,
	cl@...ux-foundation.org, riel@...hat.com,
	linux-kernel@...r.kernel.org, rientjes@...gle.com
Subject: Re: [PATCH 1/2] mm: Introduce GFP_PANIC for early-boot allocations


* Pekka Enberg <penberg@...helsinki.fi> wrote:

> Ingo Molnar wrote:
>> * Pekka Enberg <penberg@...helsinki.fi> wrote:
>>
>>> Hi Andrew,
>>>
>>> Andrew Morton wrote:
>>>> On Fri, 08 May 2009 18:10:28 +0300
>>>> Pekka Enberg <penberg@...helsinki.fi> wrote:
>>>>
>>>>> +#define GFP_PANIC	(__GFP_NOFAIL | __GFP_NORETRY)
>>>> urgh, you have to be kidding me.  This significantly worsens complexity
>>>> and risk in core MM and it's just yuk.
>>>>
>>>> I think we can justify pulling such dopey party tricks to save  
>>>> pageframe space, or bits in page.flags and such.  But just to save 
>>>> a scrap of memory which would have been released during boot  
>>>> anwyay?  Don't think so.
>>> No, I wasn't kidding and I don't agree that it "significantly  
>>> worsens complexity". The point is not to save memory but to clearly 
>>> annotate those special call-sites that really don't need to check for 
>>> out-of-memory.
>>
>> Frankly, i cannot believe that so many smart people dont see the  
>> simple, universal, un-arguable truism in the following statement:
>>
>>  it is shorter, tidier, more maintainable, more reviewable to write:
>>
>> 	ptr = kmalloc(GFP_BOOT, size);
>>
>>  than to write:
>>
>> 	ptr = kmalloc(GFP_KERNEL, size);
>> 	BUG_ON(!ptr);
>
> Hey, that's a much better name! I guess we don't need to support 
> GFP_ATOMIC? I'll repost the series with Peter's system_state != 
> BOOTING warning. Lets see if that makes the patch more palatable 
> to Andrew.

Hey, and as we all know, names do matter! We are much better off 
hacking Linux not Freax, after all.

Successful projects need good names, and anyone who doesnt know that 
must be a true git. Hm, wait a minute ...

	Ingo
--
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/