linux-kernel - Re: Page Allocation Failure and Page allocation stalls

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

Date:   Thu, 02 May 2019 01:21:19 -0400
From:   "Valdis KlÄ“tnieks" <valdis.kletnieks@...edu>
To:     Pankaj Suryawanshi <pankajssuryawanshi@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        kernelnewbies@...nelnewbies.org, Vlastimil Babka <vbabka@...e.cz>,
        Michal Hocko <mhocko@...nel.org>, minchan@...nel.org
Subject: Re: Page Allocation Failure and Page allocation stalls

On Thu, 02 May 2019 04:56:05 +0530, Pankaj Suryawanshi said:

> Please help me to decode the error messages and reason for this errors.

> [ 3205.818891] HwBinder:1894_6: page allocation failure: order:7, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

Order 7 - so it wants 2**7 contiguous pages.  128 4K pages.

> [ 3205.967748] [<802186cc>] (__alloc_from_contiguous) from [<80218854>] (cma_allocator_alloc+0x44/0x4c)

And that 3205.nnn tells me the system has been running for almost an hour. Going
to be hard finding that much contiguous free memory.

Usually CMA is called right at boot to avoid this problem - why is this
triggering so late?

> [  671.925663] kworker/u8:13: page allocation stalls for 10090ms, order:1, mode:0x15080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null)

That's.... a *really* long stall.

> [  672.031702] [<8021e800>] (copy_process.part.5) from [<802203b0>] (_do_fork+0xd0/0x464)
> [  672.039617]  r10:00000000 r9:00000000 r8:9d008400 r7:00000000 r6:81216588 r5:9b62f840
> [  672.047441]  r4:00808111
> [  672.049972] [<802202e0>] (_do_fork) from [<802207a4>] (kernel_thread+0x38/0x40)
> [  672.057281]  r10:00000000 r9:81422554 r8:9d008400 r7:00000000 r6:9d004500 r5:9b62f840
> [  672.065105]  r4:81216588
> [  672.067642] [<8022076c>] (kernel_thread) from [<802399b4>] (call_usermodehelper_exec_work+0x44/0xe0)

First possibility that comes to mind is that a usermodehelper got launched, and
it then tried to fork with a very large active process image.  Do we have any
clues what was going on?  Did a device get hotplugged?

Content of type "application/pgp-signature" skipped