panic: pmap_page_protect: illegal for unmanaged page

[Matthew Dillon]

:>     pages under PV management due to the physical-to-virtual translations
:>     that might be needed in that codepath... device pages tend to be at
:>     physical addresses that just don't work with the way the translation code
:>     was written.
:
:It happens if you call msync() with an argument of MS_INVALIDATE.
:
:So you suggest to simply return?
:
:What I wonder is, will *any* page of a OBJT_DEVICE not be PG_FICTITIOUS?  In other words:  shouldn't we simply avoid the whole invalidate code path for OBJT_DEVICE objects?
:
:I'm quite confused about the intentions of this, anyways:
:...

    I *THINK* so.  I am not entirely sure with regards to block devices like
    raw disks that you might mmap.  I think those are handled as OBJT_VNODE.

:from vm_map_clean:
:                        int clean_only = 
:                                (object->type == OBJT_DEVICE) ? FALSE : TRUE;
:                        vm_object_reference(object);
:                        switch(current->maptype) {
:                        case VM_MAPTYPE_NORMAL:
:                                vm_object_page_remove(object,
:                                    OFF_TO_IDX(offset),
:                                    OFF_TO_IDX(offset + size + PAGE_MASK),
:                                    clean_only);
:
:Obviously OBJT_DEVICE is special cased, and it seems that somebody explicitly wanted that OBJT_DEVICE mappings will be completely destroyed on this call.
:...
:But then, down this code path, pmap_remove_all() will panic on PG_FICTITOUS pages.  Interesting enough, pmap_clearbit() will simply ignore PG_FICTITIOUS pages.  I think I'll try the same for pmap_remove_all() now.
:
:cheers
:  simon

    Yes, I agree that's definitely the desire there, but there's no way to
    do it there because fictitious pages are not tracked with PV lists.
    There's no way to do it at all until the VM object itself is destroyed
    in the vm_object_terminate() path.

    At the very least I think we have to check for PG_MANAGED in
    vm_object_page_remove_callback() and just return if the page is
    not managed.  PG_MANAGED is always clear if PG_FICTITIOUS is set, so
    that handles the fictitious pages while at the same time allows us to
    potentially manage them in the future without the new check blowing us up.

						-Matt