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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 Oct 2009 13:51:20 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	David Rientjes <rientjes@...gle.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Stephan von Krawczynski <skraw@...net.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Frans Pop <elendil@...net.nl>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: page allocation failure message kernel 2.6.31.4 (tty-related)

On Thu, Oct 22, 2009 at 03:36:04PM +0300, Pekka Enberg wrote:
> On Thu, Oct 22, 2009 at 1:59 PM, Mel Gorman <mel@....ul.ie> wrote:
> >> There's subtleties like where rt tasks are given ALLOC_HARDER even when
> >> in_interrupt() that are different from previous kernels and could reduce
> >> the amount of ALLOC_HIGH and ALLOC_HARDER memory that can be allocated.
> >>
> >
> > /me checks again
> >
> > I think you're right. Correct it with something like?
> >
> > ==== CUT HERE ====
> > From bca71e94e10cd93771ec5b17eccb817dd0c85360 Mon Sep 17 00:00:00 2001
> > From: Mel Gorman <mel@....ul.ie>
> > Date: Thu, 22 Oct 2009 11:55:14 +0100
> > Subject: [PATCH] page allocator: Do not allow interrupts to use ALLOC_HARDER
> >
> > Commit 341ce06f69abfafa31b9468410a13dbd60e2b237 altered watermark logic
> > slightly by allowing rt_tasks that are handling an interrupt to set
> > ALLOC_HARDER. This patch brings the watermark logic more in line with
> > 2.6.30.
> >
> > Signed-off-by: Mel Gorman <mel@....ul.ie>
> 
> Good catch.
> 
> Reviewed-by: Pekka Enberg <penberg@...helsinki.fi>
> 
> Can we have some of the people that are hitting the OOM problems test
> this patch in combination with this patch:
> 
> http://patchwork.kernel.org/patch/54215/
> 
> Mel, can you also resend these page allocator patches to Andrew? I
> haven't seen him pick the above patch in -mm and we probably want to
> get fixes into -stable soon because distributors seem to be basing
> their next releases on 2.6.31...
> 

What I'm going to do is prepare a set that assembles all the possible patches
that fix the variety of errors and get people to retest to make sure we catch
what is relevant, what isn't and what bugs (if any) are left. I should have
the set ready by the end of the day.

> > ---
> >  mm/page_alloc.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index a3e5fed..3ecf819 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1769,7 +1769,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
> >                 * See also cpuset_zone_allowed() comment in kernel/cpuset.c.
> >                 */
> >                alloc_flags &= ~ALLOC_CPUSET;
> > -       } else if (unlikely(rt_task(p)))
> > +       } else if (unlikely(rt_task(p)) && !in_interrupt())
> >                alloc_flags |= ALLOC_HARDER;
> >
> >        if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
> > --
> > 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/
> >
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ