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 ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
