linux-kernel - Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0 (was: Re: mm, page_alloc: avoid looking up the first zone in a zonelist twice)

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: <20160531101356.GS2527@techsingularity.net>
Date:	Tue, 31 May 2016 11:13:56 +0100
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux MM <linux-mm@...ck.org>,
	linux-m68k <linux-m68k@...ts.linux-m68k.org>
Subject: Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0 (was: Re: mm,
 page_alloc: avoid looking up the first zone in a zonelist twice)

On Tue, May 31, 2016 at 11:28:05AM +0200, Geert Uytterhoeven wrote:
> Hi Mel,
> 
> On Mon, May 30, 2016 at 8:56 PM, Mel Gorman <mgorman@...hsingularity.net> wrote:
> > Thanks. Please try the following instead
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index bb320cde4d6d..557549c81083 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3024,6 +3024,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> >                 apply_fair = false;
> >                 fair_skipped = false;
> >                 reset_alloc_batches(ac->preferred_zoneref->zone);
> > +               z = ac->preferred_zoneref;
> >                 goto zonelist_scan;
> >         }
> 
> Thanks a lot, that seems to fix the issue!.
> 
> Tested-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> 
> JFTR, without the fix, sometimes I get a different, but equally obscure, crash
> than the one I posted before:
> 

I'm afraid I don't recognise it. Given the nature of the previous bug
though, I have a vague suspicion that someone is not handling a page
allocation failure properly and goes boom later.

-- 
Mel Gorman
SUSE Labs