bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH gnumach] Add vm_pages_phys


From: Sergey Bugaev
Subject: Re: [PATCH gnumach] Add vm_pages_phys
Date: Wed, 31 Jan 2024 19:35:18 +0300

On Wed, Jan 31, 2024 at 2:44 PM Samuel Thibault <samuel.thibault@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



reply via email to

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