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 <[email protected]> > --- > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
