Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Markos Chandras <markos.chandras@imgtec.com>,
	<linux-mips@linux-mips.org>
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>, <stable@vger.kernel.org>
Subject: Re: [PATCH] MIPS: mm: tlbex: Fix potential HTW race on TLBL/M/S handlers
Date: Thu, 27 Nov 2014 11:42:00 +0000	[thread overview]
Message-ID: <54770E08.9040309@imgtec.com> (raw)
In-Reply-To: <1417086788-15654-1-git-send-email-markos.chandras@imgtec.com>

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

On 27/11/14 11:13, Markos Chandras wrote:
> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> 
> There is a potential race when probing the TLB in TLBL/M/S exception
> handlers for a matching entry. Between the time we hit a TLBL/S/M
> exception and the time we get to execute the TLBP instruction, the

More specifically it is between the exception being triggered and the
actual start of exception handling. HTW is disabled while at exception
level so it isn't a problem after the handler has actually started.

> HTW may have killed the TLB entry we are interested in hence the TLB

maybe s/killed/replaced/

Sorry to be picky, but I think it's worth getting that wording as
specific as possible for future reference.

> probe may fail. However, in the existing handlers, we never checked the
> status of the TLBP (ie check the result in the C0/Index register). We
> fix this by adding such a check when the core implements the HTW. If
> we couldn't find a matching entry, we return back and try again.
> 
> Cc: <stable@vger.kernel.org> # v3.17+
> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> ---
>  arch/mips/mm/tlbex.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
> index 7994368f96c4..3978a3d81366 100644
> --- a/arch/mips/mm/tlbex.c
> +++ b/arch/mips/mm/tlbex.c
> @@ -1872,8 +1872,16 @@ build_r4000_tlbchange_handler_head(u32 **p, struct uasm_label **l,
>  	uasm_l_smp_pgtable_change(l, *p);
>  #endif
>  	iPTE_LW(p, wr.r1, wr.r2); /* get even pte */
> -	if (!m4kc_tlbp_war())
> +	if (!m4kc_tlbp_war()) {
>  		build_tlb_probe_entry(p);
> +		if (cpu_has_htw) {
> +			/* race condition happens, leaving */

How about expanding this comment a bit for people trying to figure out
the code.

Technically though:
Reviewed-by: James Hogan <james.hogan@imgtec.com>

Thanks
James

> +			uasm_i_ehb(p);
> +			uasm_i_mfc0(p, wr.r3, C0_INDEX);
> +			uasm_il_bltz(p, r, wr.r3, label_leave);
> +			uasm_i_nop(p);
> +		}
> +	}
>  	return wr;
>  }
>  
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Markos Chandras <markos.chandras@imgtec.com>, linux-mips@linux-mips.org
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>, stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: mm: tlbex: Fix potential HTW race on TLBL/M/S handlers
Date: Thu, 27 Nov 2014 11:42:00 +0000	[thread overview]
Message-ID: <54770E08.9040309@imgtec.com> (raw)
Message-ID: <20141127114200.p7We_pXDnxMqIvHk8-i9LPCYDotepU7C_xQYVUsj5c4@z> (raw)
In-Reply-To: <1417086788-15654-1-git-send-email-markos.chandras@imgtec.com>

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

On 27/11/14 11:13, Markos Chandras wrote:
> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> 
> There is a potential race when probing the TLB in TLBL/M/S exception
> handlers for a matching entry. Between the time we hit a TLBL/S/M
> exception and the time we get to execute the TLBP instruction, the

More specifically it is between the exception being triggered and the
actual start of exception handling. HTW is disabled while at exception
level so it isn't a problem after the handler has actually started.

> HTW may have killed the TLB entry we are interested in hence the TLB

maybe s/killed/replaced/

Sorry to be picky, but I think it's worth getting that wording as
specific as possible for future reference.

> probe may fail. However, in the existing handlers, we never checked the
> status of the TLBP (ie check the result in the C0/Index register). We
> fix this by adding such a check when the core implements the HTW. If
> we couldn't find a matching entry, we return back and try again.
> 
> Cc: <stable@vger.kernel.org> # v3.17+
> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> ---
>  arch/mips/mm/tlbex.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
> index 7994368f96c4..3978a3d81366 100644
> --- a/arch/mips/mm/tlbex.c
> +++ b/arch/mips/mm/tlbex.c
> @@ -1872,8 +1872,16 @@ build_r4000_tlbchange_handler_head(u32 **p, struct uasm_label **l,
>  	uasm_l_smp_pgtable_change(l, *p);
>  #endif
>  	iPTE_LW(p, wr.r1, wr.r2); /* get even pte */
> -	if (!m4kc_tlbp_war())
> +	if (!m4kc_tlbp_war()) {
>  		build_tlb_probe_entry(p);
> +		if (cpu_has_htw) {
> +			/* race condition happens, leaving */

How about expanding this comment a bit for people trying to figure out
the code.

Technically though:
Reviewed-by: James Hogan <james.hogan@imgtec.com>

Thanks
James

> +			uasm_i_ehb(p);
> +			uasm_i_mfc0(p, wr.r3, C0_INDEX);
> +			uasm_il_bltz(p, r, wr.r3, label_leave);
> +			uasm_i_nop(p);
> +		}
> +	}
>  	return wr;
>  }
>  
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-11-27 11:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27 11:13 [PATCH] MIPS: mm: tlbex: Fix potential HTW race on TLBL/M/S handlers Markos Chandras
2014-11-27 11:13 ` Markos Chandras
2014-11-27 11:42 ` James Hogan [this message]
2014-11-27 11:42   ` James Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54770E08.9040309@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=Leonid.Yegoshin@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=markos.chandras@imgtec.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox