On Thu, Apr 22, 2010 at 11:56 PM, Anton Maksimenkov 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 :
>> Here is some cleanup of uvm_map.c code.
So, can I remind this simple cleanup?
2010/1/31 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 e
On Thu, Feb 04, 2010 at 10:57:49PM +0500, Anton Maksimenkov wrote:
> 2010/2/3 Owain Ainsworth :
> > ...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.
2010/2/3 Owain Ainsworth :
> ...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 trying to
> push ju
On Thu, Feb 04, 2010 at 11:51:11AM +0500, Anton Maksimenkov wrote:
> 2010/2/3 Ariane van der Steldt :
> > 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 d
2010/2/3 Ariane van der Steldt :
> 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 rather c
On Wed, Feb 03, 2010 at 04:33:50PM +0100, Ariane van der Steldt wrote:
> On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
> > 2010/2/2 Anton Maksimenkov :
> > > Overcomplicated using of RB_TREE in uvm_map_lookup_entry() making it
> > > hard to understand.
> > > I thinking about dr
On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
> 2010/2/2 Anton Maksimenkov :
> > 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 this RB_TRE
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 eve
2010/2/2 Anton Maksimenkov :
> 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 this RB_TREE.
Oh, sorry, I mean "in uvm_map_findspace()" of course.
In uvm_map_lookup_e
2010/2/1 Bob Beck :
> On 31 January 2010 05:43, Anton Maksimenkov 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 pointer even when it fai
On 31 January 2010 05:43, Anton Maksimenkov 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
with that point
12 matches
Mail list logo
