On Wed, Jan 31, 2024 at 2:44 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > I see you used kmem_alloc_pageable() over kmem_alloc() that I > > suggested. Why is that? > > Because I have seen it used so in other places, > notably host_ipc_marequest_info, host_slab_info, > host_virtual_physical_table_info
Yes, exactly because those functions don't hold VM locks :) Look at mach_vm_object_pages_phys()/_mach_vm_object_pages() for an example function that does (and actually does something close to what you're implementing here?) > > My understanding is the point of kmem_alloc() > > is to be used in cases like this, when you don't want the routine > > itself to fault while holding locks on VM objects/maps. > > That's quite subtle. Is that documented somewhere? I don't think it is. There are a couple of /* can't fault while we hold locks */ comments in ipc/mach_port.c, but there they do things slightly differently: they allocate memory with vm_allocate(), and then wire it with vm_map_pageable(). I don't know what the differences between doing that vs kmem_alloc() are. There's also kmem_alloc_wired() which does a very similar thing; the difference appears to be that kmem_alloc_wired() uses kernel_object, while kmem_alloc() creates a fresh anonymous VM object; apparently the former prevents the allocated memory from being copied with vm_map_copyin(), which means that memory basically cannot be sent in a message. But I don't really understand how this works in detail. Sergey
