linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Kees Cook <keescook@chromium.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	airlied@linux.ie, daniel@ffwll.ch, torvalds@linux-foundation.org,
	viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
	hpa@zytor.com, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH RESEND 3/4] drm/i915/gem: Replace user_access_begin by user_write_access_begin
Date: Thu, 2 Apr 2020 09:59:36 +0200	[thread overview]
Message-ID: <e5e1ad22-e3b2-5779-2662-1bd464eae175@c-s.fr> (raw)
In-Reply-To: <202004020051.649C6B8@keescook>



Le 02/04/2020 à 09:52, Kees Cook a écrit :
> On Thu, Apr 02, 2020 at 07:34:18AM +0000, Christophe Leroy wrote:
>> When i915_gem_execbuffer2_ioctl() is using user_access_begin(),
>> that's only to perform unsafe_put_user() so use
>> user_write_access_begin() in order to only open write access.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
> Why is this split from the other conversions?


I split it from the other because this one is in drivers while other 
ones are in core part of the kernel.

Is it better to squash it in the previous patch ?

Christophe

> 
> Reviewed-by: Kees Cook <keescook@chromium.org>
> 
> 
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++-----
>>   1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index 7643a30ba4cd..4be8205a70b6 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -1611,14 +1611,14 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>>   		 * happened we would make the mistake of assuming that the
>>   		 * relocations were valid.
>>   		 */
>> -		if (!user_access_begin(urelocs, size))
>> +		if (!user_write_access_begin(urelocs, size))
>>   			goto end;
>>   
>>   		for (copied = 0; copied < nreloc; copied++)
>>   			unsafe_put_user(-1,
>>   					&urelocs[copied].presumed_offset,
>>   					end_user);
>> -		user_access_end();
>> +		user_write_access_end();
>>   
>>   		eb->exec[i].relocs_ptr = (uintptr_t)relocs;
>>   	}
>> @@ -1626,7 +1626,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>>   	return 0;
>>   
>>   end_user:
>> -	user_access_end();
>> +	user_write_access_end();
>>   end:
>>   	kvfree(relocs);
>>   	err = -EFAULT;
>> @@ -2991,7 +2991,8 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
>>   		 * And this range already got effectively checked earlier
>>   		 * when we did the "copy_from_user()" above.
>>   		 */
>> -		if (!user_access_begin(user_exec_list, count * sizeof(*user_exec_list)))
>> +		if (!user_write_access_begin(user_exec_list,
>> +					     count * sizeof(*user_exec_list)))
>>   			goto end;
>>   
>>   		for (i = 0; i < args->buffer_count; i++) {
>> @@ -3005,7 +3006,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
>>   					end_user);
>>   		}
>>   end_user:
>> -		user_access_end();
>> +		user_write_access_end();
>>   end:;
>>   	}
>>   
>> -- 
>> 2.25.0
>>
> 


  reply	other threads:[~2020-04-02  7:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  7:34 [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Christophe Leroy
2020-04-02  7:34 ` [PATCH RESEND 2/4] uaccess: Selectively open read or write user access Christophe Leroy
2020-04-02  7:51   ` Kees Cook
2020-04-02  8:00     ` Christophe Leroy
2020-04-02  7:34 ` [PATCH RESEND 3/4] drm/i915/gem: Replace user_access_begin by user_write_access_begin Christophe Leroy
2020-04-02  7:52   ` Kees Cook
2020-04-02  7:59     ` Christophe Leroy [this message]
2020-04-02  7:34 ` [PATCH RESEND 4/4] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin Christophe Leroy
2020-04-02  7:52   ` Kees Cook
2020-04-02  7:46 ` [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Kees Cook
2020-04-02 16:29 ` Al Viro
2020-04-02 17:03   ` Christophe Leroy
2020-04-02 17:38     ` Kees Cook
2020-04-02 17:50     ` Al Viro
2020-04-02 18:35       ` Christophe Leroy
2020-04-02 18:35       ` Kees Cook
2020-04-02 19:26         ` Linus Torvalds
2020-04-02 20:27           ` Kees Cook
2020-04-02 20:47             ` Linus Torvalds
2020-04-03  0:58         ` Al Viro
2020-04-03  9:49           ` Russell King - ARM Linux admin
2020-04-03 11:26           ` Catalin Marinas
2020-04-03 13:37             ` Russell King - ARM Linux admin
2020-04-03 17:26               ` Al Viro
2020-04-03 10:02         ` Russell King - ARM Linux admin

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=e5e1ad22-e3b2-5779-2662-1bd464eae175@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=daniel@ffwll.ch \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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