linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Daniel Axtens <dja@axtens.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 03/15] powerpc/align: Convert emulate_spe() to user_access_begin
Date: Thu, 11 Mar 2021 06:45:39 +0100	[thread overview]
Message-ID: <cc59942e-7f8c-196d-a734-07674178e189@csgroup.eu> (raw)
In-Reply-To: <8735x2d4it.fsf@dja-thinkpad.axtens.net>



Le 10/03/2021 à 23:31, Daniel Axtens a écrit :
> Hi Christophe,
> 
>> This patch converts emulate_spe() to using user_access_being
> s/being/begin/ :)
>> logic.
>>
>> Since commit 662bbcb2747c ("mm, sched: Allow uaccess in atomic with
>> pagefault_disable()"), might_fault() doesn't fire when called from
>> sections where pagefaults are disabled, which must be the case
>> when using _inatomic variants of __get_user and __put_user. So
>> the might_fault() in user_access_begin() is not a problem.
> (likewise with the might_fault() in __get_user_nocheck, called from
> unsafe_get_user())

unsafe_get_user() call __get_user_nocheck() with do_allow = false, so there is no might_fault() there.

> 
>> There was a verification of user_mode() together with the access_ok(),
>> but the function returns in case !user_mode() immediately after
>> the access_ok() verification, so removing that test has no effect.
> 
> I agree that removing the test is safe.
> 
>> -	/* Verify the address of the operand */
>> -	if (unlikely(user_mode(regs) &&
>> -		     !access_ok(addr, nb)))
>> -		return -EFAULT;
>> -
> 
> I found the reasoning a bit confusing: I think it's safe to remove
> because:

Ok, I'll see if I can rephrase it.

> 
>   - we have the usermode check immediately following it:
> 
>>   	/* userland only */
>>   	if (unlikely(!user_mode(regs)))
>>   		return 0;
> 
>   - and then we have the access_ok() check as part of
>     user_read_access_begin later on in the function:
> 
>> +		if (!user_read_access_begin(addr, nb))
>> +			return -EFAULT;
>> +
> 
> 
>>   		switch (nb) {
>>   		case 8:
>> -			ret |= __get_user_inatomic(temp.v[0], p++);
>> -			ret |= __get_user_inatomic(temp.v[1], p++);
>> -			ret |= __get_user_inatomic(temp.v[2], p++);
>> -			ret |= __get_user_inatomic(temp.v[3], p++);
>> +			unsafe_get_user(temp.v[0], p++, Efault_read);
>> +			unsafe_get_user(temp.v[1], p++, Efault_read);
>> +			unsafe_get_user(temp.v[2], p++, Efault_read);
>> +			unsafe_get_user(temp.v[3], p++, Efault_read);
> 
> This will bail early rather than trying every possible read. I think
> that's OK. 

It tries every possible read, but at the end it bails out with EFAULT, so I see no point.

> I can't think of a situation where we could fail to read the
> first byte and then successfully read later bytes, for example. Also I
> can't think of a sane way userspace could depend on that behaviour. So I
> agree with this change (and the change to the write path).
> 
>>   			fallthrough;
>>   		case 4:
>> -			ret |= __get_user_inatomic(temp.v[4], p++);
>> -			ret |= __get_user_inatomic(temp.v[5], p++);
>> +			unsafe_get_user(temp.v[4], p++, Efault_read);
>> +			unsafe_get_user(temp.v[5], p++, Efault_read);
>>   			fallthrough;
>>   		case 2:
>> -			ret |= __get_user_inatomic(temp.v[6], p++);
>> -			ret |= __get_user_inatomic(temp.v[7], p++);
>> -			if (unlikely(ret))
>> -				return -EFAULT;
>> +			unsafe_get_user(temp.v[6], p++, Efault_read);
>> +			unsafe_get_user(temp.v[7], p++, Efault_read);
>>   		}
>> +		user_read_access_end();
>>   
>>   		switch (instr) {
>>   		case EVLDD:
>> @@ -255,31 +250,41 @@ static int emulate_spe(struct pt_regs *regs, unsigned int reg,
>>   
>>   	/* Store result to memory or update registers */
>>   	if (flags & ST) {
>> -		ret = 0;
>>   		p = addr;
>> +
>> +		if (!user_read_access_begin(addr, nb))
> 
> That should be a user_write_access_begin.

Good catch thanks.

> 
>> +			return -EFAULT;
>> +
> 
> 
>>   
>>   	return 1;
>> +
>> +Efault_read:
> 
> Checkpatch complains that this is CamelCase, which seems like a
> checkpatch problem. Efault_{read,write} seem like good labels to me.

I'm not keen of names mixing capital letters and lowercase, but Efault is the label that has been 
used almost everywhere with unsafe_get/put_user(), so I inclined myself.

> 
> (You don't need to change anything, I just like to check the checkpatch
> results when reviewing a patch.)
> 
>> +	user_read_access_end();
>> +	return -EFAULT;
>> +
>> +Efault_write:
>> +	user_write_access_end();
>> +	return -EFAULT;
>>   }
>>   #endif /* CONFIG_SPE */
>>
> 
> With the user_write_access_begin change:
>    Reviewed-by: Daniel Axtens <dja@axtens.net>
> 
> Kind regards,
> Daniel
> 

  reply	other threads:[~2021-03-11  5:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 17:46 [PATCH v2 00/15] powerpc: Cleanup of uaccess.h and adding asm goto for get_user() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 01/15] powerpc/uaccess: Remove __get_user_allowed() and unsafe_op_wrap() Christophe Leroy
2021-03-10 21:47   ` Daniel Axtens
2021-03-10 17:46 ` [PATCH v2 02/15] powerpc/uaccess: Define ___get_user_instr() for ppc32 Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 03/15] powerpc/align: Convert emulate_spe() to user_access_begin Christophe Leroy
2021-03-10 22:31   ` Daniel Axtens
2021-03-11  5:45     ` Christophe Leroy [this message]
2021-03-12 13:25   ` [PATCH v3 " Christophe Leroy
2021-04-10 14:28     ` Michael Ellerman
2021-03-10 17:46 ` [PATCH v2 04/15] powerpc/uaccess: Remove __get/put_user_inatomic() Christophe Leroy
2021-03-10 22:37   ` Daniel Axtens
2021-03-10 17:46 ` [PATCH v2 05/15] powerpc/uaccess: Move get_user_instr helpers in asm/inst.h Christophe Leroy
2021-03-25 21:59   ` Daniel Axtens
2021-03-10 17:46 ` [PATCH v2 06/15] powerpc/align: Don't use __get_user_instr() on kernel addresses Christophe Leroy
2021-03-25 22:12   ` Daniel Axtens
2021-03-10 17:46 ` [PATCH v2 07/15] powerpc/uaccess: Call might_fault() inconditionaly Christophe Leroy
2021-03-25 22:38   ` Daniel Axtens
2021-03-25 22:44     ` Daniel Axtens
2021-03-10 17:46 ` [PATCH v2 08/15] powerpc/uaccess: Remove __unsafe_put_user_goto() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 09/15] powerpc/uaccess: Remove __chk_user_ptr() in __get/put_user Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 10/15] powerpc/uaccess: Remove calls to __get_user_bad() and __put_user_bad() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 11/15] powerpc/uaccess: Split out __get_user_nocheck() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 12/15] powerpc/uaccess: Rename __get/put_user_check/nocheck Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 13/15] powerpc/uaccess: Refactor get/put_user() and __get/put_user() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 14/15] powerpc/uaccess: Introduce __get_user_size_goto() Christophe Leroy
2021-03-10 17:46 ` [PATCH v2 15/15] powerpc/uaccess: Use asm goto for get_user when compiler supports it Christophe Leroy
2021-04-10 14:28 ` [PATCH v2 00/15] powerpc: Cleanup of uaccess.h and adding asm goto for get_user() Michael Ellerman

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=cc59942e-7f8c-196d-a734-07674178e189@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=benh@kernel.crashing.org \
    --cc=dja@axtens.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).