pmap_tlb_update_addr() diagnostic message in trap()

[Jason Thorpe <thorpej%me.com@localhost>]

Hey folks --

While preparing my Qube2 to test some things, I noticed a few messages like this occasionally littering the console:

[    28.459999] pmap_tlb_update_addr(0x83e67e20,0x7de9e000,0xd169e, 0) returned 0

I can't recall having seen these before, so I dug into it a little bit.  TL;DR - I think they're harmless and the message should be commented out.  But here is my theory as to why they're happening.

This message is in the TLB_MOD handler.  This handles the case where a TLB entry exists but the TLB entry maps the page read-only for whatever reason (either because it's a truly read-only mapping or because we're detecting when the page becomes dirty -- in my case, it's the latter).

In this case, the trap handler sees that it's just marking the page dirty, so OR's in the appropriate bits into the TLB entry value, and then calls pmap_tlb_update_addr() to update the TLB hardware with the new entry.

Now, pmap_tlb_update_addr() eventually calls tlb_update_addr() which ends up as mips3_tlb_update_addr().  In this case, mips3_tlb_update_addr() is being asked to update the TLB entry for the specified VA+ASID and return true, or return false if the VA+ASID was not currently found in the TLB.

The message indicates that the VA+ASID was not found in the TLB.  But this is unexpected because we *just* got a TLB_MOD exception (not a TLB_MISS exception)!  That's why the message is logged.

But I think there's a situation where this can legitimately happen.

I'll note that this block of code in trap() disables preemption, but does NOT block interrupts.  This means that we could be getting interrupts coming in and having TLB_MISS exceptions occur while the interrupt handlers are running. The TLB miss handler is going to be issuing tlbwr (TLB Write Random) instructions to insert entries into the TLB.  It seems entirely possible that this is what's happening -- my faulting VA+ASID is an innocent victim of a tlbwr that happens during an interrupt handler.

Does anyone else see a flaw in this hypothesis or otherwise disagree that these messages are harmless?

Thx.

-- thorpej