Messages in this thread | | | Subject | Re: [PATCH] Revert "MIPS: make userspace mapping young by default". | From | Zhou Yanjie <> | Date | Sat, 8 May 2021 16:48:03 +0800 |
| |
Hi,
On 2021/4/30 上午2:04, Thomas Bogendoerfer wrote: > On Mon, Apr 26, 2021 at 09:11:47PM +0800, Huang Pei wrote: >> [ 40.873779] Cause : 4080800c (ExcCode 03) >> [ 40.877775] BadVA : 77e23000 >> [ 40.880645] PrId : 00d00100 (Ingenic XBurst) >> [ 40.884989] Modules linked in: >> [ 40.888034] Process Xsession (pid: 1370, threadinfo=ca5ce8d6, >> task=61c8f3ad, tls=77e28690) >> >> !!! This is my first time debug MIPS32 kernel, I think both threadinfo >> and task should be at KSEG0, instead of KSEG2 or USEG > don't print pointers with %p they will be garbled for security reasons. > > see Documentation/core-api/printk-formats.rst > > "A raw pointer value may be printed with %p which will hash the address > before printing." > >> [ 41.233877] Index: 27 pgmask=4kb va=77e22000 asid=5c >> [ 41.233877] [pa=06a17000 c=3 d=0 v=0 g=0] [pa=2017a000 c=0 d=0 v=0 >> g=0] >> >> !!! TLB entry is loading a SWAP entry(C=0, pa=swap) at BADV, the pte_buddy point to a valid >> PFN(C=3, pa seem ok), but it is impossible, since line 116 must flush the tlb and >> replaced swap entry with new page >> >> Am I missing something? > not sure, if I'm on the right track, but with the _PAGE_VALID bit set in > the new pte local_r4k_flush_cache_page() will do > > if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) > vaddr = NULL; > > > and then > > vaddr ? r4k_blast_dcache_page(addr) : > r4k_blast_dcache_user_page(addr); > > flush the address directly instead with r4k_blast_dcache_user_page(). > But the TLB will be updated after the cache flush (which is correct IMHO). > So setting the VALID bit too early destroys the logic of flushing > cache aliases. Do you agree ?
I think it is indeed the problem here.
After I tried to drop the _PAGE_VALID mark in the PVA (change it to "#define PVA(p) PM(_PAGE_ACCESSED | (p))"), the kernel no longer panic.
Thanks and best regards!
> > Thomas. >
| |