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] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 10:10:51 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Xishi Qiu <qiuxishi@...wei.com>
Cc:	Yisheng Xie <xieyisheng1@...wei.com>,
	Vlastimil Babka <vbabka@...e.cz>, 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 Thu 28-07-16 15:50:32, Xishi Qiu wrote:
> On 2016/7/20 15:47, Michal Hocko wrote:
> 
> > 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?
> > 
> 
> Hi Michal,
> 
> Because of our platform driver's problem, so we change the code(add GFP_DMA) to let
> it alloc from zone_dma. (on arm64 zone_dma is 0-4G)

Why would any platform driver need to access kernel thread in the DMA
zone?
-- 
Michal Hocko
SUSE Labs