[PATCH] Fix corruption error in rh_alloc_fixed()

[Paul Mackerras]

Guillaume Knispel writes:

> On Tue, 09 Dec 2008 09:16:50 -0600
> Timur Tabi <timur at freescale.com> wrote:
> 
> > Guillaume Knispel wrote:
> > 
> > > blk = NULL; at the end of the loop is what is done in the more used
> > > rh_alloc_align(), so for consistency either we change both or we use
> > > the same construction here.
> > > I also think that testing for &info->free_list is harder to understand
> > > because you must have the linked list implementation in your head
> > > (which a kernel developer should anyway so this is not so important)
> > 
> > Fair enough.
> > 
> > Acked-by: Timur Tabi <timur at freescale.com>
> > 
> 
> Kumar, can this go into your tree ?
> (copying the patch under so you have it at hand)
> 
> There is an error in rh_alloc_fixed() of the Remote Heap code:
> If there is at least one free block blk won't be NULL at the end of the
> search loop, so -ENOMEM won't be returned and the else branch of
> "if (bs == s || be == e)" will be taken, corrupting the management
> structures.
> 
> Signed-off-by: Guillaume Knispel <gknispel at proformatique.com>
> ---
> Fix an error in rh_alloc_fixed() that made allocations succeed when
> they should fail, and corrupted management structures.

What's the impact of this?  Can it cause an oops?

Is it a regression from 2.6.27?  Should we be putting it in 2.6.28?

Paul.