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
