On Dec 9, 2008, at 8:28 AM, Guillaume Knispel wrote:
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
On Dec 16, 2008, at 7:13 PM, Paul Mackerras wrote:
Kumar Gala writes:
Paul are you planning on picking this up for .28 if not I'll pick it
up for .29
I was waiting for you to say if it needed to go in .28. Sounds like
you don't think it's that urgent then?
Since I have another patch for
Kumar Gala writes:
> Paul are you planning on picking this up for .28 if not I'll pick it
> up for .29
I was waiting for you to say if it needed to go in .28. Sounds like
you don't think it's that urgent then?
Paul.
___
Linuxppc-dev mailing list
Lin
The problem obviously only affect people that make use of
rh_alloc_fixed(), which is the case when you program an MCC or a QMC
controller of the CPM. Without the patch cpm_muram_alloc_fixed()
succeed when it should not, for example when trying to allocate out of
range areas or already allocated a
On Mon, 15 Dec 2008 08:21:05 +1100
Paul Mackerras wrote:
> Guillaume Knispel writes:
>
> > On Tue, 09 Dec 2008 09:16:50 -0600
> > Timur Tabi wrote:
> >
> > > Guillaume Knispel wrote:
> > >
> > > > blk = NULL; at the end of the loop is what is done in the more used
> > > > rh_alloc_align(), so
Guillaume Knispel writes:
> On Tue, 09 Dec 2008 09:16:50 -0600
> Timur Tabi 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
On Tue, 09 Dec 2008 09:16:50 -0600
Timur Tabi 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 &in
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 l
On Tue, 09 Dec 2008 09:03:19 -0600
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Guillaume Knispel wrote:
> > 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 e
Guillaume Knispel wrote:
> 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
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: Guil
11 matches
Mail list logo
