xfs
[Top] [All Lists]

Re: [Bug 335] New: XFS Oops with 2.6.7-rc3

To: Andi Kleen <ak@xxxxxx>
Subject: Re: [Bug 335] New: XFS Oops with 2.6.7-rc3
From: Chris Wedgwood <cw@xxxxxxxx>
Date: Wed, 9 Jun 2004 15:43:18 -0700
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <m3k6yhknae.fsf@averell.firstfloor.org>
References: <200406090934.i599YaKP022234@oss.sgi.com> <m3k6yhknae.fsf@averell.firstfloor.org>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Wed, Jun 09, 2004 at 01:01:45PM +0200, Andi Kleen wrote:

> This patch fixes it. The problem is that XFS expects __GFP_NOFAIL to
> never return NULL, but it returns NULL anyways when PF_MEMALLOC is
> set for the current process. This patch just readds looping in the
> XFS allocator.

I thought we had something like this?  Anyhow, since this does appear
to be required and it's been about for a while --- I wonder why it's
not been merged?

> +     /* __GFP_NOFAIL doesn't work properly when PF_MEMALLOC is already 
> +        set, and this can happen in XFS when it is called in low memory
> +        situations to free up some cached data. Loop on our own.
> +
> +        This has some deadlock potential in extreme OOM cases.
> +
> +        It would be better to use mempools for the allocations that 
> +        are used from the low memory paths (iput, writepage); like
> +        for the transactions. */

Trim the comment?


  --cw


<Prev in Thread] Current Thread [Next in Thread>