linux-kernel - Re: [Question]page allocation failure: order:2, mode:0x2000d1

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:	Wed, 20 Jul 2016 09:47:23 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Yisheng Xie <xieyisheng1@...wei.com>
Cc:	Vlastimil Babka <vbabka@...e.cz>, Xishi Qiu <qiuxishi@...wei.com>,
	minchan@...nel.org, mgorman@...e.de, iamjoonsoo.kim@....com,
	mina86@...a86.com, Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	cl@...ux.com, David Rientjes <rientjes@...gle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Hanjun Guo <guohanjun@...wei.com>
Subject: Re: [Question]page allocation failure: order:2, mode:0x2000d1

On Wed 20-07-16 09:33:30, Yisheng Xie wrote:
> 
> 
> On 2016/7/19 22:14, Vlastimil Babka wrote:
> > On 07/19/2016 03:48 PM, Xishi Qiu wrote:
[...]
> >> mode:0x2000d1 means it expects to alloc from zone_dma, (on arm64 zone_dma is 0-4G)
> > 
> > Yes, but I don't see where the __GFP_DMA comes from. The backtrace
> > suggests it's alloc_thread_info_node() which uses THREADINFO_GFP
> > which is GFP_KERNEL | __GFP_NOTRACK. There shouldn't be __GFP_DMA,
> > even on arm64. Are there some local modifications to the kernel
> > source?
> > 
> >> The page cache is very small(active_file:292kB inactive_file:240kB),
> >> so did_some_progress may be zero, and will not retry, right?
> > 
> > Could be, and then __alloc_pages_may_oom() has this:
> > 
> >         /* The OOM killer does not needlessly kill tasks for lowmem */
> >         if (ac->high_zoneidx < ZONE_NORMAL)
> >                 goto out;
> > 
> > So no oom and no faking progress for non-costly order that would
> > result in retry, because of that mysterious __GFP_DMA...
> 
> hi Vlastimil,
> We do make change and add __GFP_DMA flag here for our platform driver's problem.

Why would you want to force thread_info to the DMA zone?

> Another question is why it will do retry here, for it will goto out
> with did_some_progress=0 ?
> 
>              if (!did_some_progress)
>                  goto nopage;

Do you mean:
                /*
                 * If we fail to make progress by freeing individual
                 * pages, but the allocation wants us to keep going,
                 * start OOM killing tasks.
                 */
                if (!did_some_progress) {
                        page = __alloc_pages_may_oom(gfp_mask, order, ac,
                                                        &did_some_progress);
                        if (page)
                                goto got_pg;
                        if (!did_some_progress)
                                goto nopage;
                }

If yes then this code simply tells that if even oom path didn't make any
progress then we should fail. As DMA request doesn't invoke OOM killer
because it is effectively a lowmem request (see above check pointed
by Vlastimil) then the OOM path couldn't make any progress and we are
failing. If invoked the OOM killer then we would consider this as a
forward progress and retry the allocation request.
-- 
Michal Hocko
SUSE Labs