From nobody Wed Nov 19 18:29:23 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dBVPx4BjFz6J57r for ; Wed, 19 Nov 2025 18:29:41 +0000 (UTC) (envelope-from friedrichdoku2030@u.northwestern.edu) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBVPw6V8zz3Yt7 for ; Wed, 19 Nov 2025 18:29:40 +0000 (UTC) (envelope-from friedrichdoku2030@u.northwestern.edu) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-450a2886683so130b6e.3 for ; Wed, 19 Nov 2025 10:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u-northwestern-edu.20230601.gappssmtp.com; s=20230601; t=1763576975; x=1764181775; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C8VVMha47OKfUpaERQKMCG8sQeaFxsNR6hQauYAw66w=; b=ThSZLm1lSpjZ4eTjSIj2etsVDN0QfrdmdMuv3y7Eo3wfX4rhSBqB4/vndFk9I3yC4T Yp6LERnCA5G1FbKty93aneTHYlwcYPwmICu7oijGu29yuAUeRhYLDSaQXpomwa44a9Ly IJqrwQKTuDw9YwNxwDSRYpDu3Hstg3CDda0ahWQ9Vbf5iJMthtsZnHrOw/XZ0lYosdU9 QcKTeFtgDhW+ceNTWgUdvIm0WhyjWKY0L4P3KZlYOIi744PV6B7BCU9EEGzRSmr7yrWg pR0MzPbuakADyCoEcqaNNGXq2Lvhcert78levAUg9X37Gz24ak/WmEyMQfFbNq4R1/Rr +O8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763576975; x=1764181775; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=C8VVMha47OKfUpaERQKMCG8sQeaFxsNR6hQauYAw66w=; b=BvRRYBYcUpWuZw826Gka2wE2CnkQIKnKkm0A7osr0TmdfBxsnfDCgZwAmIYetZ+Nbt 4yeq7j2OKGzmlG7y2SCY/dpn0HoxKxgBAM2smW4S/7/idH6vid4YJAWqjy9cYHNzwSji 3p+nS0UuibA4vEDhzipvvZvaZiPp8NfdD/cDuUujHwmJ2xkFdP7C4b/z6wI+dGN6evlU qr5h18QMg1LpDWkOEkyUsnbN41wA2uZo3od14l708IhJKyw98ejZy3GPT4EU5TXSvxs4 Va7mpj18EQLp1XvBAOTYe8pRXIxFjvWPseBE21+z8dEBCI/HU5AnxGMWlF7b7j5tbTM6 8B3A== X-Gm-Message-State: AOJu0Ywf9rcOZ9ShSrlbMPhZXJLJSmGWBWenHVa3IVkpBHIp4kx0pRQL JNtdKwFS9JnLL3Hu3M4GPT0omRkHjisKuChZZbgREs5QeZbq9C1SM1GIm1OMjoRJCNgDfEldA5N k4qz35BPg9Kjeo50wp2EmHzgxw45tJbmtTRZhHuA0gw== X-Gm-Gg: ASbGncudoOF4hDWz7bhdXL0NBqPVSP0jn924XyL1Fzt/5fWMCfloeFzKYme42JwoVqb OenbzCFs0oKOlihSx++75Ter7Xv3668SbFjznCi6Svm0B0O0/jiQ+9vYKsHq8beVINF8rKEZXAL NrPIeXOjtubL+XdOb8GP6n0r84UsAhomnyvKg3NkOvN3KwK1l1S3jmtUBMet1J/a8DJIDV+OqOI elo/mGeAU5hxpFw4ymi0M/shcWVo8HExN6kJ1thnxUS3X1CUNBtiIXumoDGagBPOuw1RmzQL1lB vPdb+4jZJ9V+yiseaMTcClTRwzaIWoxkieh0CcxfsCmi31wvzMmDGArR X-Google-Smtp-Source: AGHT+IEBtZ7rffHJ3nMzDqn+3iWeIDo690o+zarvEBHGC8Xm3oohwn51RRIRjHdG6Fa9MdWLMhcMRF4/2PnfPmMtuaA= X-Received: by 2002:a05:6808:244e:b0:450:d3af:ba43 with SMTP id 5614622812f47-450ff3d5476mr60020b6e.8.1763576974940; Wed, 19 Nov 2025 10:29:34 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Friedrich Doku Date: Wed, 19 Nov 2025 12:29:23 -0600 X-Gm-Features: AWmQ_blp2c8yaxCuJbmG3wZwga8eVYPht3aDyRelQG9Z3690nOvycv9-XaJ3UBU Message-ID: Subject: Re: Kernel panic when using pmap_extract_and_hold() to check physical-to-virtual address mapping To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000202e790643f6c3e5" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBVPw6V8zz3Yt7 --000000000000202e790643f6c3e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 . I'll run this again, so I can get the output from the crash. --Friedrich On Wed, Nov 19, 2025 at 12:15=E2=80=AFPM Mark Johnston = 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 virtua= l > > address space of a user space process. We are trying to do this from th= e > > 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 =3D=3D &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() a= nd > > 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 addre= ss > > in a user space process. I'm doing this from a kernel module via sysctl > > handler. > > > > Best, > > Friedy > --000000000000202e790643f6c3e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your response.=C2=A0

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

It could be possible that I'm getting vmspace0. Maybe it'= s returning that, but I haven't checked. Here's my full code. I'll run thi= s again, so I can get the output from the crash.=C2=A0

--Friedrich



On Wed, Nov 19, 2025 at 12:15=E2=80=AFPM Mark Johnston <markj@freebsd.org> w= rote:
On Wed, No= v 19, 2025 at 11:51:02AM -0600, Friedrich Doku wrote:
> Hello,
>
> We want to see if a specific physical address is mapped into the virtu= al
> address space of a user space process. We are trying to do this from t= he
> 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:
>
>=C2=A0 =C2=A0 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?

>=C2=A0 =C2=A0 2. p->p_vmspace - gets the vmspace from the process
Is it possible that p->p_vmspace =3D=3D &vmspace0?

>=C2=A0 =C2=A0 3. vmspace_pmap(p->p_vmspace) - extracts the pmap from= vmspace
>
> Then I'm iterating through vm_map entries with VM_MAP_ENTRY_FOREAC= H() and
> calling pmap_extract_and_hold(pmap, va, VM_PROT_READ) for each virtual=
> address.

Unrelated to your question, but this seems very slow.=C2=A0 Each physical page carries a list of virtual mappings which refer to it, the "PV
entry" list.=C2=A0 You could instead look up the page by physical addr= ess
(PHYS_TO_VM_PAGE()) and then walk the PV entry list for the page to find its mappings.=C2=A0 This comes with a couple of caveats:
- PV entries are implemented in machine dependent code, i.e., in the
=C2=A0 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=
=C2=A0 user address spaces via so-called "managed" mappings.

> The crash happens when calling pmap_extract_and_hold(). I suspect it&#= 39;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 s= ysctl
> handler.
>
> Best,
> Friedy
--000000000000202e790643f6c3e5--