On 06/25/2012 03:33 PM, 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;

And in good kernel:

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

Signed-off-by: Caspar Zhang <redacted>
---
 testcases/kernel/mem/vma/vma01.c |   35 ++++++++++++++++++++++-------------
 1 files changed, 22 insertions(+), 13 deletions(-)

Both patches worked on my systems including: i386/x86_64, powerpc,
s/390x. I'll commit it in next a few days if I hear no objection for this.

Thanks,
Caspar


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list