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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100315143653.294c0650@nehalam>
Date:	Mon, 15 Mar 2010 14:36:53 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	David Miller <davem@...emloft.net>
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

On Mon, 15 Mar 2010 14:32:25 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:

> 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>

The kernel has both fixes in it. The customer reported that if both
were reverted, the kernel panic went away.


commit 1bfc1db036675e61af0ea34d3ac18206de566b64
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.
    
    commit 70abc8cb90e679d8519721e2761d8366a18212a6 upstream.
    
    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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

commit 550b1d3896894543cc13dafe6910119024177482
Author: Roger Oksanen <roger.oksanen@...helsinki.fi>
Date:   Sun Nov 29 17:17:29 2009 -0800

    e100: Use pci pool to work around GFP_ATOMIC order 5 memory allocation failu
    
    commit 98468efddb101f8a29af974101c17ba513b07be1 upstream.
    
    pci_alloc_consistent uses GFP_ATOMIC allocation that may fail on some system
    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>


--
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/