markjdb
commented
2 months ago So DRM maintains a global linked list of VMA structures that reference mapped GEM objects. The VM object corresponding to a GEM object keeps a pointer to the GEM object in handle; during a fault, we look up the VMA using the handle as a key. We crashed because we took a fault but couldn't find the mapping VMA in the global list.
The VM object and GEM object look fine, i.e., they're valid, haven't been destroyed. The refcount on the VM object is 2. Interestingly, at the time of the panic, a child process of plasmashell was in the middle of exec'ing, so it was busy freeing its mappings and dropping VM object references.
In drm_fstub_do_mmap(), we allocate a VMA and insert it into the global list. But apparently we handle the case where the key already exists, i.e., the GEM object has already been mapped via more than one VM object. In this case, we don't insert the VMA:
523 rw_wlock(&drm_vma_lock);
524 TAILQ_FOREACH(ptr, &drm_vma_head, vm_entry) {
525 if (ptr->vm_private_data == vm_private_data)
526 break;
527 }
528 /* check if there is an existing VM area struct */
529 if (ptr != NULL) {
530 /* check if the VM area structure is invalid */
531 if (ptr->vm_ops == NULL ||
532 ptr->vm_ops->open == NULL ||
533 ptr->vm_ops->close == NULL) {
534 rv = ESTALE;
535 vm_no_fault = 1;
536 } else {
537 rv = EEXIST;
538 vm_no_fault = (ptr->vm_ops->fault == NULL);
539 }
540 } else {
541 /* insert VM area structure into list */
542 TAILQ_INSERT_TAIL(&drm_vma_head, vmap, vm_entry);
543 rv = 0;
544 vm_no_fault = (vmap->vm_ops->fault == NULL);
545 }
546 rw_wunlock(&drm_vma_lock);
547
548 if (rv != 0) {
549 /* free allocated VM area struct */
550 drm_vmap_free(vmap);
551 /* check for stale VM area struct */
552 if (rv != EEXIST)
553 return (rv);
554 }
555
556 /* check if there is no fault handler */
557 if (vm_no_fault) {
558 *obj = cdev_pager_allocate(vm_private_data,
559 OBJT_DEVICE, &drm_dev_pg_ops, size, prot,
560 *foff, td->td_ucred);
561 } else {
562 *obj = cdev_pager_allocate(vm_private_data,
563 OBJT_MGTDEVICE, &drm_mgtdev_pg_ops, size, prot,
564 *foff, td->td_ucred);
565 }So in the rv = EEXIST case, it looks like we can end up with >1 VM object that references the same GEM object. When one of those VM objects is destroyed (maybe triggered by the child process exec()ing), the corresponding VMA will be removed from the global list, but then a fault on a different referencing VM object will fail to look up a VMA, and we'll trigger the panic that Robert hit. I can't really see any other way it could happen.
Thus my questions are:
- Under what circumstances does
drm_fstub_do_mmap()find an existing GEM object in the global list? - If there is a legitimate explanation for 1, how do we handle it? A refcount on the VMA list entries would help, but some of those fields assume that the mapping is unique. That is, if you have two mappings referencing a GEM object via the VMA list, what meaning do the
vm_startandvm_endfields of the VMA have? @bukinr do you have any idea what causes 1)?
bukinr
rwatson
Running with a kernel/userlevel from #2080, I saw this kernel panic when starting an aarch64 Chromium web browser within an otherwise entirely purecap (kernel, userlevel, desktop) environment:
panic: Assertion vmap != NULL failed at /usr/src/sys/dev/drm/freebsd/drm_os_freebsd.c:370The kernel build was:
FreeBSD cheri-blossom.sec.cl.cam.ac.uk 15.0-CURRENT FreeBSD 15.0-CURRENT #19 c18n_procstat-n268168-8e6f163a2c50: Tue Apr 9 02:29:44 UTC 2024 robert@cheri-blossom.sec.cl.cam.ac.uk:/usr/obj/usr/src/arm64.aarch64c/sys/GENERIC-MORELLO-PURECAP arm64Async revocation and default enabled c18n are both turned on:
Console output:
KGDB on the crashdump reports:
The process in question was
plasmashell