public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Caspar Zhang <caspar@casparzhang.com>
To: hejianet@linux.vnet.ibm.com, Wang Sheng-Hui <shhuiw@gmail.com>
Cc: LTP list <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] [PATCH] mm/vma01: consider topdown and bottomup allocation
Date: Mon, 25 Jun 2012 11:46:50 +0800	[thread overview]
Message-ID: <4FE7DF2A.4010208@casparzhang.com> (raw)
In-Reply-To: <1340594555-32059-1-git-send-email-caspar@casparzhang.com>

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;
> 
> And in good kernel:
> 
>     start_addr1 == t && end_addr1 == u;
>     start_addr2 == u && end_addr2 == t+6*ps;
> 
> Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
> ---
>  testcases/kernel/mem/vma/vma01.c |   35 ++++++++++++++++++++++-------------
>  1 files changed, 22 insertions(+), 13 deletions(-)
> 

The patch itself passes my test, yet I give it a self-NAK for now. Needs
one more patch to resolve the issue hejianet brought up.

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

      reply	other threads:[~2012-06-25  3:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25  3:22 [LTP] [PATCH] mm/vma01: consider topdown and bottomup allocation Caspar Zhang
2012-06-25  3:46 ` Caspar Zhang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FE7DF2A.4010208@casparzhang.com \
    --to=caspar@casparzhang.com \
    --cc=hejianet@linux.vnet.ibm.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=shhuiw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox