From nobody Wed Nov 19 18:15:46 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 4dBV5x25rHz6J4L5 for ; Wed, 19 Nov 2025 18:15:49 +0000 (UTC) (envelope-from markj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBV5x1CCCz3XDf; Wed, 19 Nov 2025 18:15:49 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763576149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wo+nn5aEn8+Nf1bk/SBUxctdLTC4hkvUATzoYItGNrQ=; b=kzPg+ULPCyTxrJDFLdlDCQDx0yjW5KItjyYBTE0peU02m44Vi6ynOgsjvzap/foZO2egZu L1gyDVWjApkBkx8RAKrl7Xou84O0jPS1NUIADXcfqj6ye2kP7+ryxRUnB1/fEYvGheBlxp TJ3cep3N1Yg/ev8atBflMSoJ/WfekCh1uPI1g8MX5+3X0OG74SU+mRhjfjeloJpaSaTdJ6 VqW6pXlehicYIOvcHS1TdNR1YiL19v03Cx/yPaBCeYMiMmi59/XmQeD5bjQGYya6yNZvV/ rpRXyvu4gnPhyV93WtugxmU5+P5RszLR1phetPLh8e7PQ8TZi7eFyj+aba6blw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763576149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wo+nn5aEn8+Nf1bk/SBUxctdLTC4hkvUATzoYItGNrQ=; b=wVkndr97Km2kq4mLpwoEYi+rJNcpOgUvOo+sKo3PYrAbhHYUSInXK+ibYdHzYecQqPCjq7 n88RGyEoiTYBVdnbqJyFWlDobZUcpVfKUJOK54nX6xChD1sQxdYdzaTLKIMzDX+bwrvr7P oFVYltFyRkNLU4Vc8Q+cE9uBau0QQJHDEp+IE+h/9WpoIJpcmecBp7NHckQ+hrGMRcZQmT 1+faXmrByYJd6EH0VY6MO3WoRy4pELKBAf7A+CBHHUbEWVJabqFgO7eo4EwJHCeZ2zXnwA BNDNFoYH2ak2TGC9RGO0+lFRfxhPN5mFAXwOHpm6kNmuvtO4+dLCNz5EgMxbrw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763576149; a=rsa-sha256; cv=none; b=ixGLq9jCdqIEh5ERYdA2OKrrEnf7y+uFOBmojefx06XHB7mx4LWvvEpIR2rGG1Sd3lrKA5 BJ1X09SYvQkyyVZt2O6eJrAdvjGcwn+xLGVzTip+6++Oaz9WUp3TvzlYCD/T94wJf/ehlI ovg5xk1dmhi6AzTQO78cQTs9WpBAsCt0yb58XjDFfwFP3r/JquNLxHzxX3X4jPyV5KtE+x JaUd8FWtBlYUnZvW6nhCLZPFBhiWtNErRzI6IMDA1hb58zNkXN2nzJxYk8iCtYLADC8vlj FPy8Z17Z8812H8RtQ+akhPsqFE4udU3F3LSCzRpM1Y4RMQTZ6wFrDixhWAHQCg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dBV5w6V83zJ5r; Wed, 19 Nov 2025 18:15:48 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Wed, 19 Nov 2025 13:15:46 -0500 From: Mark Johnston To: Friedrich Doku Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel panic when using pmap_extract_and_hold() to check physical-to-virtual address mapping Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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