linux-kernel - Re: [Stable-review] [19/39] e100: Use pci pool to work around GFP

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]

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/