Change Details

If an illegal instruction is encountered on a process running on a powerpc64 kernel it would attempt to sync the cache before retrying the instruction "just in case". However, since curpmap is not set, when moea64_sync_icache() attempts to lock the pmap, it's locking on a NULL pointer, triggering a panic. Since pmap_activate is always called after pmap_deactivate, there is no need to clean up the pcpu curpmap in moea64_deactivate. The pairing is done with all interrupts off.

If an illegal instruction is encountered on a process running on a powerpc64 kernel it would attempt to sync the cache before retrying the instruction "just in case". However, since curpmap is not set, when moea64_sync_icache() attempts to lock the pmap, it's locking on a NULL pointer, triggering a panic. Fix this by adding a (assumed unnecessary) fallback to curthread's pmap in moea64_sync_icache().

If an illegal instruction is encountered on a process running on a powerpc64 kernel it would attempt to sync the cache before retrying the instruction "just in case". However, since curpmap is not set, when moea64_sync_icache() attempts to lock the pmap, it's locking on a NULL pointer, triggering a panic. Since pmap_activate is always called after pmap_deactivate, there is no need to clean up the pcpu curpmap in moea64_deactivate. The pairing is done with all interrupts offFix this by adding a (assumed unnecessary) fallback to curthread's pmap in moea64_sync_icache().