[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-mips
Subject:    Re: [PATCH] MIPS: tlbex: fix a missing statement for HUGETLB
From:       Aurelien Jarno <aurelien () aurel32 ! net>
Date:       2014-08-04 13:05:06
Message-ID: 20140804130506.GA27352 () hall ! aurel32 ! net
[Download RAW message or body]

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@aurel32.net>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[prev in list] [next in list] [prev in thread] [next in thread]