Re: Kernel panic when using pmap_extract_and_hold() to check physical-to-virtual address mapping

Thank you for your response.

It happens every time we run the scan. Also, we're not checking for these
flags. Our test process is a simple user space program that mmaps memory
and waits, so P_WEXIT shouldn't be set, but we're not explicitly filtering
for it.

It could be possible that I'm getting vmspace0. Maybe it's returning that,
but I haven't checked. Here's my full code <https://pastebin.com/7NnTFXtv>.
I'll run this again, so I can get the output from the crash.
--Friedrich




On Wed, Nov 19, 2025 at 12:15 PM Mark Johnston <markj@freebsd.org> wrote:

> On Wed, Nov 19, 2025 at 11:51:02AM -0600, Friedrich Doku wrote:
> > Hello,
> >
> > We want to see if a specific physical address is mapped into the virtual
> > address space of a user space process. We are trying to do this from the
> > kernel, but we are running into issues with trying to use pmap_extract,
> > specifically we get the following kernel panic:
> >
> > panic: mtx_lock() of spin mutex (invalid)
>
> Does it always happen, or just sometimes?
>
> > The pmap pointer comes from:
> >
> >    1. pfind(target_pid) - gets the process structure
>
> Is it possible that one of P_WEXIT or P_SYSTEM is set in the p_flag
> field of the process?
>
> >    2. p->p_vmspace - gets the vmspace from the process
>
> Is it possible that p->p_vmspace == &vmspace0?
>
> >    3. vmspace_pmap(p->p_vmspace) - extracts the pmap from vmspace
> >
> > Then I'm iterating through vm_map entries with VM_MAP_ENTRY_FOREACH() and
> > calling pmap_extract_and_hold(pmap, va, VM_PROT_READ) for each virtual
> > address.
>
> Unrelated to your question, but this seems very slow.  Each physical
> page carries a list of virtual mappings which refer to it, the "PV
> entry" list.  You could instead look up the page by physical address
> (PHYS_TO_VM_PAGE()) and then walk the PV entry list for the page to find
> its mappings.  This comes with a couple of caveats:
> - PV entries are implemented in machine dependent code, i.e., in the
>   pmap layer, so some of your code would need to live there too.
> - PV entries don't record all mappings, just those that are mapped into
>   user address spaces via so-called "managed" mappings.
>
> > The crash happens when calling pmap_extract_and_hold(). I suspect it's
> > trying to acquire pmap locks that conflict with something.
> >
> > I'm trying to find which virtual address maps to a given physical address
> > in a user space process. I'm doing this from a kernel module via sysctl
> > handler.
> >
> > Best,
> > Friedy
>