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 <james.hogan@xxxxxxxxxx> wrote: > On 04/08/14 14:05, Aurelien Jarno wrote: >> On Mon, Aug 04, 2014 at 11:08:50AM +0100, James Hogan wrote: >>> Hi Aurelien, >>> >>> On 02/08/14 22:35, Aurelien Jarno wrote: >>>> On Thu, Jul 31, 2014 at 10:33:55AM -0700, David Daney wrote: >>>>> 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@xxxxxxxxxxx> > > Likewise: > > Reviewed-by: James Hogan <james.hogan@xxxxxxxxxx> > > Cheers > James > >> Tested-by: Aurelien Jarno <aurelien@xxxxxxxxxxx> >> > >
