Re: [PATCH] Huge changes in mm.c

[Vincent Guffens]

Vincent Pelletier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi.
>
> In my attempt to port grub 2 to usparc, I had big problems with all the
> memory allocation things, so I decided to rewrite the functions after
> reading them (I wasn't able to understand at all 20% of the code).
>
> Some comments :
> It *seems* that before the alloc'ed chunks weren't linked any more with
> other chunks. Now all the chunks of a region are part of the same ring.
> Chunks were allocated from the end of the memory to the beginning, I
> kept this behaviour.

From what I understood by reading the sources, the allocated chunks 
were not linked to other free chunks as you can easily recover the 
header of such an allocated memory chunk by using the pointer returned 
by the malloc function. This is simply p-1. It is not possible to free 
an allocated region without that pointer anyway as it is not possible to 
know if someone is still using that memory region. It must be released 
by the one who called the malloc.

> It *seems* that the chunk headers were "forgotten" in the malloc
> process, which led to my problems on usparc : a chunk was overwriting
> the header of the previous one. It's now fixed.

Maybe it is specific of that architecture. The function grub_malloc 
calls grub_memalign (0, size). Then the size is converted in blocks with

grub_size_t n = ((size + GRUB_MM_ALIGN - 1) >> GRUB_MM_ALIGN_LOG2) + 1;

which adds the extra block for the header. Which headers were 
overwritten exactly, I spent quite some time on that code and I couldn't 
see any problem except for the "grub free magic is broken" problem but 
off course it was not with that architecture in mind.

--
                                Vincent Guffens
                                PhD Student UCL/CESAME
                                tel:   +32 10 47 80 30
Value your freedom, or you will lose it, teaches history.
"Don't bother us with politics," respond those who don't want to learn.
                -- Richard M. Stallman