bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager


From: Justus Winter
Subject: Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager
Date: Thu, 26 May 2016 17:16:51 +0200
User-agent: alot/0.3.8.dev

Quoting Justus Winter (2016-05-18 13:27:13)
> > Backing up one step: what is actually being done here in mach-defpager?
> > Again from just a quick look, is the idea to use wired memory for all of
> > mach-defpager's process memory?

Yes, wiring the memory is required to avoid deadlocks [0].

0: 
http://darnassus.sceen.net/~rbraun/hurd_related_papers/mach/moving_the_default_memory_manager_out_of_the_mach_kernel.pdf

> > So, for example, if now some mach-defpager code calls calloc, it will now
> > get non-wired "glibc" memory instead of wired "kalloc" memory.  The
> > problem here is not mach-defpager's own code (which we can easily
> > verify/control), but the problems is the libraries it links against,
> > which currently are: libihash, libpthread, glibc itself, and any
> 
> And indeed libihash uses calloc.
> 
> > dependencies these may have.  Can we be sure these are not internally
> > using calloc, for example?
> > 
> > Now, this is not a new problem that you introduced ;-) -- previously we
> > also didn't provide malloc's memalign and realloc hooks, and realloc is
> > used quite commonly, I suppose?
> > 
> > If my theories are correct, do we need to use a different mechanism to
> > get the whole mach-defpager process into wired memory?
> 
> As Richard said in #hurd, implement mlockall and MCL_FUTURE and just
> use the default allocator.
> 
> I'd suggest reverting that change, or is the removal of that
> deprecated interface imminent?

Wdyt?

Cheers,
Justus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]