[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