linux-kernel - Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO

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]

Message-ID: <561E13FD.2070206@intel.com>
Date:	Wed, 14 Oct 2015 16:36:13 +0800
From:	Pan Xinhui <xinhuix.pan@...el.com>
To:	Michal Hocko <mhocko@...nel.org>
CC:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>, vbabka@...e.cz,
	rientjes@...gle.com, hannes@...xchg.org, nasa4836@...il.com,
	mgorman@...e.de, alexander.h.duyck@...hat.com,
	aneesh.kumar@...ux.vnet.ibm.com,
	"yanmin_zhang@...ux.intel.com" <yanmin_zhang@...ux.intel.com>
Subject: Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

hello, Michal
	thanks for your kind reply!
On 2015年10月14日 15:41, Michal Hocko wrote:
> On Wed 14-10-15 13:58:05, Pan Xinhui wrote:
>> Hi, all
>> 	I am working on some debug features' development.
>> I use kmalloc in some places of *scheduler*.
> 
> This sounds inherently dangerous.
> 
that's how we found weird bugs. :)

>> And the gfp_flag is GFP_ATOMIC, code looks like 
>> p = kmalloc(sizeof(*p), GFP_ATOMIC);
>>
>> however I notice GFP_ATOMIC is still not enough. because when system
>> is at low memory state, slub might try to wakeup kswapd. then some
>> weird issues hit.
> 
> gfp flags have been reworked in the current mmotm tree so you want
> __GFP_ATOMIC here. This will be non sleeping allocation which won't even
> wake up kswapd. I guess you do not want/need to touch memory reserves
> for something like a debugging feature (so you do not have to abuse
> __GFP_HIGH)
> 

In my debug patches, I need __GFP_HIGH.
There is one special test case, in boot stage, we will reserve a big range of memory, to try to detect if all drivers can handle low-memory in correct ways.
So maybe I need my own kmalloc succeed.

what I need to do now is just clear __GFP_KSWAPD_RECLAIM in kmalloc.

> [...]
> 
>> After some simple check, I change my codes. this time code looks like:
>> p = kmalloc(sizeof(*p), GFP_ATOMIC | __GFP_NO_KSWAPD);
>> I think this flag will forbid slub to call any scheduler codes. But issue still hit. :(
>>
>> my test result shows that __GFP_NO_KSWAPD is cleared when slub pass gfp_flag to page allocator!!!
>>
>> at last I found it is clear by codes below.
>> 1441 static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
>> 1442 {
>> 1443         if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
>> 1444                 pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
>> 1445                 BUG();
>> 1446         }
>> 1447 
>> 1448         return allocate_slab(s,
>> 1449                 flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);//all other flags will be cleared. my god!!!
>> 1450 }
>>
>> I think GFP_RECLAIM_MASK should include as many available flags as possible. :)
> 
> Not really. It should only contain those which are really reclaim
> related. The fact that SLUB drops other flags is an internal detail
> of the allocator. If the resulting memory doesn't match the original
> requirements (e.g. zone placing etc...) then it is certainly a bug
> but not a bug in GFP_RECLAIM_MASK.
> 
oh, yes. thanks for explanation.

> Anyway you are right that GFP_RECLAIM_MASK should contain
> __GFP_NO_KSWAPD resp. its new representation which is the case in the
> current mmotm tree as pointed out in previous response.
> 

I am glad to see someone has fix it, too :)


thanks
xinhui
--
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/