Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455

From: Neel Chauhan <>
Date: Thu, 17 Jun 2021 05:16:56 UTC
Hi Mark,

Thank you so much for your response!

On 2021-06-16 14:05, Mark Johnston wrote:
> The function in question appears to implement a device page fault
> handler.  In FreeBSD, such handlers are responsible only for ensuring
> that the requested page(s) are present in the VM object backing the
> mapping that was faulted on.  The generic fault handler in
> sys/vm/vm_fault.c is responsible for actually updating the faulting
> process' page tables by calling pmap_enter().  In other words, our 
> fault
> handler interface is quite different from OpenBSD's and their example
> should not be followed exactly.  Adding a vm_object_busy() call in the
> loop will silence the assertion I guess but the handler is still wrong.

Good to hear. No wonder why I still had the "blank screen of death" with 
the (now previous) code.

> If you look further down at vm_fault_gtt() (and in earlier versions of
> the DRM drivers, i915_gem_fault()), the remap_io_mapping()
> implementation in the LinuxKPI does basically what I'm describing.
> Something similar is required for vm_fault_cpu(), though I don't quite
> understand when vm_fault_cpu() is supposed to be used.

I have some code to implement remap_io_sg() based on remap_io_mapping(), 
but it's not complete.

I am still trying to figure out how to get the physical address. Right 
now, I have:

My get_pfn() function (Lines 221-231) attempts to get the physical 
address, and it is called at Line 248.

Note: This code is probably incorrect, since it gives me an "page 
already inserted" panic.

Any hints on where the physical address is? Should we have an 
FreeBSD-specific "pa" argument for the physical address if it's needed?

Sorry for the kernel newbie questions.

-Neel (nc@)