linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: will@kernel.org, catalin.marinas@arm.com,
	linux-arm-kernel@lists.infradead.org, yangyingliang@huawei.com
Subject: Re: [PATCH 8/8] arm64: Rewrite __arch_clear_user()
Date: Wed, 12 May 2021 14:51:01 +0100	[thread overview]
Message-ID: <f2a48ade-ad95-c17e-1a12-e4d038f0dc11@arm.com> (raw)
In-Reply-To: <20210512130418.GF88854@C02TD0UTHF1T.local>

On 2021-05-12 14:06, Mark Rutland wrote:
> On Wed, May 12, 2021 at 12:31:39PM +0100, Robin Murphy wrote:
>> On 2021-05-12 11:48, Mark Rutland wrote:
>>> On Tue, May 11, 2021 at 05:12:38PM +0100, Robin Murphy wrote:
>>>> Rewrite __arch_clear_user() with regular
>>>> USER() annotations so that it's clearer what's going on, and take the
>>>> opportunity to minimise the branchiness in the most common paths, which
>>>> also allows the exception fixup to return a more accurate result.
>>>
>>> IIUC this isn't always accurate for the {4,2,1}-byte cases; example
>>> below. I'm not sure whether that's intentional since the commit message
>>> says "more accurate" rather than "accurate".
>>
>> Indeed, the "more" was definitely significant :)
> 
> :)
> 
>>> If we think that under-estimating is fine, I reckon it'd be worth a
>>> comment to make that clear.
>>
>> Indeed for smaller amounts there's no change in fixup behaviour at all, but
>> I have to assume that underestimating by up to 100% is probably OK since
>> we've been underestimating by fully 100% for nearly 10 years now. I don't
>> believe it's worth having any more complexity than necessary for the fault
>> case - grepping for clear_user() usage suggests that nobody really cares
>> about the return value beyond whether it's zero or not, so the minor
>> "improvement" here is more of a nice-to-have TBH.
>>
>> The existing comment doesn't actually explain anything either, which is why
>> I didn't replace it, but I'm happy to add something if you like.
> 
> I don't have strong feelings either way, but I think that we should at
> least document this, since that'll at least save us rehashing the same
> point in future. :)
> 
> That said, IIUC to make this always accurate we only need two ADDs (diff
> below). Since those will only be executed at most once each, I suspect
> they won't have a measureable impact in practice.
> 
> So maybe it's worth adding them to avoid any risk that someone needs
> this to be accurate in future?

Hmm, now that you've caused me to ponder it some more, it can in fact be 
achieved with just two extra ADDs _out of line_, and still neatly enough 
that I'm now definitely going to do that. Thanks for the push!

Robin.

> 
> Mark.
> 
> ---->8----
> diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
> index 1005345b4066..7ef553ec2677 100644
> --- a/arch/arm64/lib/clear_user.S
> +++ b/arch/arm64/lib/clear_user.S
> @@ -32,12 +32,14 @@ USER(9f, sttr       xzr, [x2, #-8])
>   
>   2:     tbz     x1, #2, 3f
>   USER(9f, sttr  wzr, [x0])
> +       add     x0, x0, #4
>   USER(9f, sttr  wzr, [x2, #-4])
>          mov     x0, #0
>          ret
>   
>   3:     tbz     x1, #1, 4f
>   USER(9f, sttrh wzr, [x0])
> +       add     x0, x0, #2
>   4:     tbz     x1, #0, 5f
>   USER(9f, sttrb wzr, [x2, #-1])
>   5:     mov     x0, #0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-12 13:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 16:12 [PATCH 0/8] arm64: String function updates Robin Murphy
2021-05-11 16:12 ` [PATCH 1/8] arm64: Import latest version of Cortex Strings' memcmp Robin Murphy
2021-05-12 13:28   ` Mark Rutland
2021-05-12 13:38     ` Robin Murphy
2021-05-12 14:51       ` Szabolcs Nagy
2021-05-26 10:17         ` Mark Rutland
2021-05-11 16:12 ` [PATCH 2/8] arm64: Import latest version of Cortex Strings' strcmp Robin Murphy
2021-05-11 16:12 ` [PATCH 3/8] arm64: Import updated version of Cortex Strings' strlen Robin Murphy
2021-05-11 16:12 ` [PATCH 4/8] arm64: Import latest version of Cortex Strings' strncmp Robin Murphy
2021-05-11 16:12 ` [PATCH 5/8] arm64: Add assembly annotations for weak-PI-alias madness Robin Murphy
2021-05-11 16:12 ` [PATCH 6/8] arm64: Import latest memcpy()/memmove() implementation Robin Murphy
2021-05-11 16:12 ` [PATCH 7/8] arm64: Better optimised memchr() Robin Murphy
2021-05-14 14:55   ` Catalin Marinas
2021-05-14 18:38     ` Robin Murphy
2021-05-11 16:12 ` [PATCH 8/8] arm64: Rewrite __arch_clear_user() Robin Murphy
2021-05-12 10:48   ` Mark Rutland
2021-05-12 11:31     ` Robin Murphy
2021-05-12 13:06       ` Mark Rutland
2021-05-12 13:51         ` Robin Murphy [this message]
2021-05-14 11:57   ` [PATCH v2] " Robin Murphy
2021-05-26 11:15     ` Mark Rutland
2021-05-27 13:24       ` Robin Murphy

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=f2a48ade-ad95-c17e-1a12-e4d038f0dc11@arm.com \
    --to=robin.murphy@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=will@kernel.org \
    --cc=yangyingliang@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).