Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2021-01-11 09:18:00
Also in:
dri-devel, intel-gfx, linux-btrfs, linux-fsdevel, linux-mm, linuxppc-dev, lkml, nouveau, sparclinux, virtualization
On 2021-01-09 01:33:52 [+0100], Thomas Bogendoerfer wrote:
quoted hunk ↗ jump to hunk
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:quoted
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote:quoted
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening?not yet, kernel crash log of a Malta QEMU is below.update: This dirty hack lets the Malta QEMU boot again:diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c@@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable();set_pte_at() tries to update cache and could do an kmap_atomic() there.
So the old implementation used set_pte() while the new one uses set_pte_at().
Not sure, if this is allowed at this point.
The problem is the recursion
kmap_atomic() -> __update_cache() -> kmap_atomic()
and kmap_local_idx_push() runs out if index space before stack space.
I'm not sure if the __update_cache() worked for highmem. It has been
added for that in commit
f4281bba81810 ("MIPS: Handle highmem pages in __update_cache")
but it assumes that the address returned by kmap_atomic() is the same or
related enough for flush_data_cache_page() to work.
Thomas.
Sebastian