Now what should we do? My original patch is not perfect, but it has
already merged into Ralf's tree (but hasn't merged in Linus's tree).
Let me send Ralf a new version of this patch? Or let David send
another patch on top of my original one?

Huacai

On Mon, Aug 4, 2014 at 9:10 PM, James Hogan [off-list ref] wrote:

On 04/08/14 14:05, Aurelien Jarno wrote:

quoted

On Mon, Aug 04, 2014 at 11:08:50AM +0100, James Hogan wrote:

quoted

Hi Aurelien,

On 02/08/14 22:35, Aurelien Jarno wrote:

quoted

On Thu, Jul 31, 2014 at 10:33:55AM -0700, David Daney wrote:

quoted

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index f99ec587..341add1 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c

@@ -1299,6 +1299,8 @@ static void build_r4000_tlb_refill_handler(void)
        }
 #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
        uasm_l_tlb_huge_update(&l, p);
+       if (!use_bbit_insns())
+               UASM_i_LW(&p, K0, 0, K1);
        build_huge_update_entries(&p, htlb_info.huge_pte, K1);
        build_huge_tlb_write_entry(&p, &l, &r, K0, tlb_random,
                                   htlb_info.restore_scratch);

This patch fixes the issue, thanks. That said it doesn't look fully
correct. The test should be done the same way as for
build_fast_tlb_refill_handler. For example the fast handler is not
called on a 32-bit machine with bbit instructions, so it would need
to reload K0.

In the non fast case build_is_huge_pte() will still use bbit1 if
available after restoring K0, and I don't think the bbit1 would clobber
K0 when the branch is taken, so I think the test for !use_bbit_insns()
is correct.

Oh you are right! Therefore this second patch is:

Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>

Likewise:

Reviewed-by: James Hogan <redacted>

Cheers
James

quoted

Tested-by: Aurelien Jarno <aurelien@aurel32.net>