Re: some cleanup of of uvm_map.c

2010-04-22 Thread Anton Maksimenkov
So, can I remind this simple cleanup? 2010/1/31 Anton Maksimenkov anton...@gmail.com: Here is some cleanup of uvm_map.c code. At first, in uvm_map_advice() function. Let it looks as simple as uvm_map_inherit() - no need to lock/unlock map just to realize that sanity check fail. Also no need

Re: some cleanup of of uvm_map.c

2010-04-22 Thread Ted Unangst
On Thu, Apr 22, 2010 at 11:56 PM, Anton Maksimenkov anton...@gmail.com wrote: So, can I remind this simple cleanup? Thanks, applied, but next time watch the tabs vs spaces when mailing a diff. 2010/1/31 Anton Maksimenkov anton...@gmail.com: Here is some cleanup of uvm_map.c code.

Re: some cleanup of of uvm_map.c

2010-02-04 Thread Ariane van der Steldt
On Thu, Feb 04, 2010 at 11:51:11AM +0500, Anton Maksimenkov wrote: 2010/2/3 Ariane van der Steldt ari...@stack.nl: On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote: uvm_map_lookup_entry()... in uvm_map_findspace()... I'm pretty sure that function is bugged: I think it

Re: some cleanup of of uvm_map.c

2010-02-04 Thread Anton Maksimenkov
2010/2/3 Owain Ainsworth zer...@googlemail.com: ...you can't just go straight to the start of the map. Say i386 where W^X is done using segments. if you dump something right at the other end of the segment, that pretty much screws it. Perhaps going back to the min hint for the protection and

Re: some cleanup of of uvm_map.c

2010-02-03 Thread Ariane van der Steldt
On Sun, Jan 31, 2010 at 05:43:02PM +0500, Anton Maksimenkov wrote: Here is some cleanup of uvm_map.c code. At first, in uvm_map_advice() function. Let it looks as simple as uvm_map_inherit() - no need to lock/unlock map just to realize that sanity check fail. Also no need to do it in every

Re: some cleanup of of uvm_map.c

2010-02-03 Thread Ariane van der Steldt
On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote: 2010/2/2 Anton Maksimenkov anton...@gmail.com: Overcomplicated using of RB_TREE in uvm_map_lookup_entry() making it hard to understand. I thinking about drop this RB_TREE out from uvm_map.c or completely rewrite using of

Re: some cleanup of of uvm_map.c

2010-02-03 Thread Anton Maksimenkov
2010/2/3 Ariane van der Steldt ari...@stack.nl: On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote: uvm_map_lookup_entry()... in uvm_map_findspace()... I'm pretty sure that function is bugged: I think it doesn't do wrap-around on the search for an entry.  Both functions are

Re: some cleanup of of uvm_map.c

2010-02-01 Thread Bob Beck
On 31 January 2010 05:43, Anton Maksimenkov anton...@gmail.com wrote: Here is some cleanup of uvm_map.c code. Second, remove redundant temp_entry variable from both functions. One entry variable is enough to do the job. I don't think you want to do that.. uvm_map_lookup_entry can screw

Re: some cleanup of of uvm_map.c

2010-02-01 Thread Anton Maksimenkov
2010/2/1 Bob Beck b...@ualberta.ca: On 31 January 2010 05:43, Anton Maksimenkov anton...@gmail.com wrote: Second, remove redundant temp_entry variable from both functions. One entry variable is enough to do the job. I don't think you want to do that.. uvm_map_lookup_entry can screw with that

some cleanup of of uvm_map.c

2010-01-31 Thread Anton Maksimenkov
Here is some cleanup of uvm_map.c code. At first, in uvm_map_advice() function. Let it looks as simple as uvm_map_inherit() - no need to lock/unlock map just to realize that sanity check fail. Also no need to do it in every loop. Second, remove redundant temp_entry variable from both functions