Caspar Zhang | 25 Jun 2012 05:22
Gravatar

[PATCH] mm/vma01: consider topdown and bottomup allocation


When calculating VMAs, results differ in topdown and bottomup memory
allocation mechanisms. This patch fix the potential failures and should
work like below:

In topdown allocation, the start addr in second VMA should be smaller
than first one, i.e.:

    u======t------(t+3*ps)
      2nd    1st

Thus, in buggy kernel, if we find a VMA mapping entry in child like:

    start_addr == u && end_addr == t+3*ps;

the test would go fail. Otherwise, in good kernel, we should see

    start_addr1 == u && end_addr1 == t;
    start_addr2 == t && end_addr2 == t+3*ps;

While in bottomup allocation, it's different:

    t------u======(t+6*ps)
      1st    2nd

Here in buggy kernel, we can see VMA mapping entry like this:

    start_addr == t && end_addr == t+6*ps;

And in good kernel:
(Continue reading)

Caspar Zhang | 25 Jun 2012 05:46
Gravatar

Re: [PATCH] mm/vma01: consider topdown and bottomup allocation

On 06/25/2012 11:22 AM, Caspar Zhang wrote:
> 
> When calculating VMAs, results differ in topdown and bottomup memory
> allocation mechanisms. This patch fix the potential failures and should
> work like below:
> 
> In topdown allocation, the start addr in second VMA should be smaller
> than first one, i.e.:
> 
>     u======t------(t+3*ps)
>       2nd    1st
> 
> Thus, in buggy kernel, if we find a VMA mapping entry in child like:
> 
>     start_addr == u && end_addr == t+3*ps;
> 
> the test would go fail. Otherwise, in good kernel, we should see
> 
>     start_addr1 == u && end_addr1 == t;
>     start_addr2 == t && end_addr2 == t+3*ps;
> 
> While in bottomup allocation, it's different:
> 
>     t------u======(t+6*ps)
>       1st    2nd
> 
> Here in buggy kernel, we can see VMA mapping entry like this:
> 
>     start_addr == t && end_addr == t+6*ps;
> 
(Continue reading)


Gmane