[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100315.143225.212581877.davem@davemloft.net>
Date: Mon, 15 Mar 2010 14:32:25 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: shemminger@...tta.com
Cc: gregkh@...e.de, linux-kernel@...r.kernel.org, stable@...nel.org,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
roger.oksanen@...helsinki.fi
Subject: Re: [Stable-review] [19/39] e100: Use pci pool to work around
GFP_ATOMIC order 5 memory allocation failure
From: Stephen Hemminger <shemminger@...tta.com>
Date: Mon, 15 Mar 2010 14:29:53 -0700
> On Tue, 05 Jan 2010 12:02:15 -0800
> Greg KH <gregkh@...e.de> wrote:
>
>> 2.6.31-stable review patch. If anyone has any objections, please let us know.
>>
>> ------------------
>>
>> From: Roger Oksanen <roger.oksanen@...helsinki.fi>
>>
>> commit 98468efddb101f8a29af974101c17ba513b07be1 upstream.
>>
>> pci_alloc_consistent uses GFP_ATOMIC allocation that may fail on some systems
>> with limited memory (Bug #14265). pci_pool_alloc allows waiting with
>> GFP_KERNEL.
>>
>> Tested-by: Karol Lewandowski <karol.k.lewandowski@...il.com>
>> Signed-off-by: Roger Oksanen <roger.oksanen@...helsinki.fi>
>> Signed-off-by: David S. Miller <davem@...emloft.net>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
>
>
> These two e100 patches in 2.6.31.10 (and 2.6.32) caused kernel panic on one customer
> system. I recommend they be reverted in next --stable update.
There was a subsequent fix that explicitly zeros out the memory.
The problem was that whilst pci_alloc_consistent() zeros out
the memory it returns, the pci pool stuff does not.
So please get that fix sent to -stable instead of the revert.
For reference:
commit 70abc8cb90e679d8519721e2761d8366a18212a6
Author: Roger Oksanen <roger.oksanen@...helsinki.fi>
Date: Fri Dec 18 20:18:21 2009 -0800
e100: Fix broken cbs accounting due to missing memset.
Alan Stern noticed that e100 caused slab corruption.
commit 98468efddb101f8a29af974101c17ba513b07be1 changed
the allocation of cbs to use dma pools that don't return zeroed memory,
especially the cb->status field used to track which cb to clean, causing
(the visible) double freeing of skbs and a wrong free cbs count.
Now the cbs are explicitly zeroed at allocation time.
Reported-by: Alan Stern <stern@...land.harvard.edu>
Tested-by: Alan Stern <stern@...land.harvard.edu>
Signed-off-by: Roger Oksanen <roger.oksanen@...helsinki.fi>
Acked-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
--
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