Guillaume Knispel writes: > On Tue, 09 Dec 2008 09:16:50 -0600 > Timur Tabi <ti...@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 <ti...@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 <gknis...@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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev