On Tue, 2019-05-28 at 17:23 -0700, David Miller wrote: > From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > Date: Mon, 27 May 2019 14:10:56 -0700 > > > These two patches address issues with the recently added > > VM_FLUSH_RESET_PERMS vmalloc flag. > > > > Patch 1 addresses an issue that could cause a crash after other > > architectures besides x86 rely on this path. > > > > Patch 2 addresses an issue where in a rare case strange arguments > > could be provided to flush_tlb_kernel_range(). > > It just occurred to me another situation that would cause trouble on > sparc64, and that's if someone the address range of the main kernel > image ended up being passed to flush_tlb_kernel_range(). > > That would flush the locked kernel mapping and crash the kernel > instantly in a completely non-recoverable way. Hmm, I haven't received the logs from Meelis that will show the real ranges being passed into flush_tlb_kernel_range() on sparc, but it should be flushing a range spanning from the modules to the direct map. It looks like the kernel is at the very bottom of the address space, so not included. Or do you mean the pages that hold the kernel text on the direct map? But regardless of this new code, DEBUG_PAGEALLOC hangs with the first vmalloc free/unmap. That should be just flushing a single allocation in the vmalloc range. If it is somehow catching a locked entry though... Are there any sparc flush mechanisms that could be used in vmalloc that won't touch locked entries? Peter Z was pointing out that flush_tlb_all() might be more approriate for vmalloc anyway.
