Date: Fri, 18 Jun 2021 09:57:15 -0400 From: Mark Johnston <markj@freebsd.org> To: Neel Chauhan <nc@freebsd.org> Cc: current@freebsd.org Subject: Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455 Message-ID: <YMymO0fYbsHoK05J@nuc> In-Reply-To: <8bd27c2a72ebfa9299bca7d930297faf@FreeBSD.org> References: <e542a0c737f24d15df0fadd985e94938@neelc.org> <YMpnf3DcEw6A/rzD@nuc> <8bd27c2a72ebfa9299bca7d930297faf@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 16, 2021 at 10:16:56PM -0700, Neel Chauhan wrote: > 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: > > https://github.com/neelchauhan/drm-kmod/commit/92a3d9bb585acb55c1dab9c5ed11190f7db73ecf > > 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. That seems surprising, since the vm_page_grab() call should return the page at pidx if one exists. > Any hints on where the physical address is? Should we have an > FreeBSD-specific "pa" argument for the physical address if it's needed? I'm not sure. I'll just note that the Linux code appears to be trying to map a set of pages belonging to a scatter-gather list. Taking the physical address of the first page and assuming that all subsequent pages are physically contiguous doesn't seem correct, but this is what is happening in that loop, since each iteration simply increments pa by PAGE_SIZE.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YMymO0fYbsHoK05J>