[Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:

  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled

This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
-- and indirectly, sign_extend64() -- from the user_access_begin/end
critical region (i.e, with SMAP disabled).

While it's probably harmless in this case, in general we like to avoid
extra function calls in SMAP-disabled regions because it can open up
inadvertent security holes.

Fix it by moving the gen8_canonical_addr() conversion to a separate loop
before user_access_begin() is called.

Note that gen8_canonical_addr() is now called *before* masking off the
PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
extension and ignores the masked lower bits anyway.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d5a0f5ae4a8b..183cab13e028 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
 			u64_to_user_ptr(args->buffers_ptr);
 		unsigned int i;
 
+		/*
+		 * Do the call to gen8_canonical_addr() outside the
+		 * uaccess-enabled region to minimize uaccess exposure.
+		 */
+		for (i = 0; i < args->buffer_count; i++)
+			exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);
+
 		/* Copy the new buffer offsets back to the user's exec list. */
 		/*
 		 * Note: count * sizeof(*user_exec_list) does not overflow,
@@ -2962,9 +2969,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
 			if (!(exec2_list[i].offset & UPDATE))
 				continue;
 
-			exec2_list[i].offset =
-				gen8_canonical_addr(exec2_list[i].offset & PIN_OFFSET_MASK);
-			unsafe_put_user(exec2_list[i].offset,
+			unsafe_put_user(exec2_list[i].offset & PIN_OFFSET_MASK,
 					&user_exec_list[i].offset,
 					end_user);
 		}
-- 
2.21.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:

  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled

This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
-- and indirectly, sign_extend64() -- from the user_access_begin/end
critical region (i.e, with SMAP disabled).

While it's probably harmless in this case, in general we like to avoid
extra function calls in SMAP-disabled regions because it can open up
inadvertent security holes.

Fix it by moving the gen8_canonical_addr() conversion to a separate loop
before user_access_begin() is called.

Note that gen8_canonical_addr() is now called *before* masking off the
PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
extension and ignores the masked lower bits anyway.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d5a0f5ae4a8b..183cab13e028 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
 			u64_to_user_ptr(args->buffers_ptr);
 		unsigned int i;
 
+		/*
+		 * Do the call to gen8_canonical_addr() outside the
+		 * uaccess-enabled region to minimize uaccess exposure.
+		 */
+		for (i = 0; i < args->buffer_count; i++)
+			exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);
+
 		/* Copy the new buffer offsets back to the user's exec list. */
 		/*
 		 * Note: count * sizeof(*user_exec_list) does not overflow,
@@ -2962,9 +2969,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
 			if (!(exec2_list[i].offset & UPDATE))
 				continue;
 
-			exec2_list[i].offset =
-				gen8_canonical_addr(exec2_list[i].offset & PIN_OFFSET_MASK);
-			unsafe_put_user(exec2_list[i].offset,
+			unsafe_put_user(exec2_list[i].offset & PIN_OFFSET_MASK,
 					&user_exec_list[i].offset,
 					end_user);
 		}
-- 
2.21.1

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Chris Wilson]

Quoting Josh Poimboeuf (2020-02-27 22:08:26)
> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> 
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> 
> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> -- and indirectly, sign_extend64() -- from the user_access_begin/end
> critical region (i.e, with SMAP disabled).
> 
> While it's probably harmless in this case, in general we like to avoid
> extra function calls in SMAP-disabled regions because it can open up
> inadvertent security holes.
> 
> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> before user_access_begin() is called.
> 
> Note that gen8_canonical_addr() is now called *before* masking off the
> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> extension and ignores the masked lower bits anyway.
> 
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d5a0f5ae4a8b..183cab13e028 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
>                         u64_to_user_ptr(args->buffers_ptr);
>                 unsigned int i;
>  
> +               /*
> +                * Do the call to gen8_canonical_addr() outside the
> +                * uaccess-enabled region to minimize uaccess exposure.
> +                */
> +               for (i = 0; i < args->buffer_count; i++)
> +                       exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);


Another loop over all the objects, where we intentionally try and skip
unmodified entries? To save 2 instructions from inside the second loop?

Colour me skeptical.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Chris Wilson]

Quoting Josh Poimboeuf (2020-02-27 22:08:26)
> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> 
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> 
> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> -- and indirectly, sign_extend64() -- from the user_access_begin/end
> critical region (i.e, with SMAP disabled).
> 
> While it's probably harmless in this case, in general we like to avoid
> extra function calls in SMAP-disabled regions because it can open up
> inadvertent security holes.
> 
> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> before user_access_begin() is called.
> 
> Note that gen8_canonical_addr() is now called *before* masking off the
> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> extension and ignores the masked lower bits anyway.
> 
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d5a0f5ae4a8b..183cab13e028 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
>                         u64_to_user_ptr(args->buffers_ptr);
>                 unsigned int i;
>  
> +               /*
> +                * Do the call to gen8_canonical_addr() outside the
> +                * uaccess-enabled region to minimize uaccess exposure.
> +                */
> +               for (i = 0; i < args->buffer_count; i++)
> +                       exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);


Another loop over all the objects, where we intentionally try and skip
unmodified entries? To save 2 instructions from inside the second loop?

Colour me skeptical.
-Chris

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Al Viro]

On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> 
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> 
> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> -- and indirectly, sign_extend64() -- from the user_access_begin/end
> critical region (i.e, with SMAP disabled).
> 
> While it's probably harmless in this case, in general we like to avoid
> extra function calls in SMAP-disabled regions because it can open up
> inadvertent security holes.
> 
> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> before user_access_begin() is called.
> 
> Note that gen8_canonical_addr() is now called *before* masking off the
> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> extension and ignores the masked lower bits anyway.

How painful would it be to inline the damn thing?
<looks>
static inline u64 gen8_canonical_addr(u64 address)
{
        return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
}
static inline __s64 sign_extend64(__u64 value, int index)
{
        __u8 shift = 63 - index;
        return (__s64)(value << shift) >> shift;
}

What the hell?  Josh, what kind of .config do you have that these are
_not_ inlined?  And why not mark gen8_canonical_addr() __always_inline?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Al Viro]

On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> 
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> 
> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> -- and indirectly, sign_extend64() -- from the user_access_begin/end
> critical region (i.e, with SMAP disabled).
> 
> While it's probably harmless in this case, in general we like to avoid
> extra function calls in SMAP-disabled regions because it can open up
> inadvertent security holes.
> 
> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> before user_access_begin() is called.
> 
> Note that gen8_canonical_addr() is now called *before* masking off the
> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> extension and ignores the masked lower bits anyway.

How painful would it be to inline the damn thing?
<looks>
static inline u64 gen8_canonical_addr(u64 address)
{
        return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
}
static inline __s64 sign_extend64(__u64 value, int index)
{
        __u8 shift = 63 - index;
        return (__s64)(value << shift) >> shift;
}

What the hell?  Josh, what kind of .config do you have that these are
_not_ inlined?  And why not mark gen8_canonical_addr() __always_inline?

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

On Thu, Feb 27, 2020 at 10:35:42PM +0000, Al Viro wrote:
> On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
> > With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> > 
> >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> > 
> > This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> > -- and indirectly, sign_extend64() -- from the user_access_begin/end
> > critical region (i.e, with SMAP disabled).
> > 
> > While it's probably harmless in this case, in general we like to avoid
> > extra function calls in SMAP-disabled regions because it can open up
> > inadvertent security holes.
> > 
> > Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> > before user_access_begin() is called.
> > 
> > Note that gen8_canonical_addr() is now called *before* masking off the
> > PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> > extension and ignores the masked lower bits anyway.
> 
> How painful would it be to inline the damn thing?
> <looks>
> static inline u64 gen8_canonical_addr(u64 address)
> {
>         return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
> }
> static inline __s64 sign_extend64(__u64 value, int index)
> {
>         __u8 shift = 63 - index;
>         return (__s64)(value << shift) >> shift;
> }
> 
> What the hell?  Josh, what kind of .config do you have that these are
> _not_ inlined?

I think this was seen with CONFIG_CC_OPTIMIZE_FOR_SIZE, which tends to
ignore inline.

> And why not mark gen8_canonical_addr() __always_inline?

Right, marking those two functions as __always_inline is the other
option.  The problem is, if you keep doing it, eventually you end up
with __always_inline-itis spreading all over the place.  And it affects
all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
At least this fix is localized.

But I agree my patch isn't ideal either.

-- 
Josh

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

On Thu, Feb 27, 2020 at 10:35:42PM +0000, Al Viro wrote:
> On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
> > With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
> > 
> >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
> > 
> > This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
> > -- and indirectly, sign_extend64() -- from the user_access_begin/end
> > critical region (i.e, with SMAP disabled).
> > 
> > While it's probably harmless in this case, in general we like to avoid
> > extra function calls in SMAP-disabled regions because it can open up
> > inadvertent security holes.
> > 
> > Fix it by moving the gen8_canonical_addr() conversion to a separate loop
> > before user_access_begin() is called.
> > 
> > Note that gen8_canonical_addr() is now called *before* masking off the
> > PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
> > extension and ignores the masked lower bits anyway.
> 
> How painful would it be to inline the damn thing?
> <looks>
> static inline u64 gen8_canonical_addr(u64 address)
> {
>         return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
> }
> static inline __s64 sign_extend64(__u64 value, int index)
> {
>         __u8 shift = 63 - index;
>         return (__s64)(value << shift) >> shift;
> }
> 
> What the hell?  Josh, what kind of .config do you have that these are
> _not_ inlined?

I think this was seen with CONFIG_CC_OPTIMIZE_FOR_SIZE, which tends to
ignore inline.

> And why not mark gen8_canonical_addr() __always_inline?

Right, marking those two functions as __always_inline is the other
option.  The problem is, if you keep doing it, eventually you end up
with __always_inline-itis spreading all over the place.  And it affects
all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
At least this fix is localized.

But I agree my patch isn't ideal either.

-- 
Josh

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Randy Dunlap]

On 2/27/20 5:03 PM, Josh Poimboeuf wrote:
> On Thu, Feb 27, 2020 at 10:35:42PM +0000, Al Viro wrote:
>> On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
>>> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
>>>
>>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
>>>
>>> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
>>> -- and indirectly, sign_extend64() -- from the user_access_begin/end
>>> critical region (i.e, with SMAP disabled).
>>>
>>> While it's probably harmless in this case, in general we like to avoid
>>> extra function calls in SMAP-disabled regions because it can open up
>>> inadvertent security holes.
>>>
>>> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
>>> before user_access_begin() is called.
>>>
>>> Note that gen8_canonical_addr() is now called *before* masking off the
>>> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
>>> extension and ignores the masked lower bits anyway.
>>
>> How painful would it be to inline the damn thing?
>> <looks>
>> static inline u64 gen8_canonical_addr(u64 address)
>> {
>>         return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
>> }
>> static inline __s64 sign_extend64(__u64 value, int index)
>> {
>>         __u8 shift = 63 - index;
>>         return (__s64)(value << shift) >> shift;
>> }
>>
>> What the hell?  Josh, what kind of .config do you have that these are
>> _not_ inlined?
> 
> I think this was seen with CONFIG_CC_OPTIMIZE_FOR_SIZE, which tends to

so the commit message correctly says.

> ignore inline.
> 
>> And why not mark gen8_canonical_addr() __always_inline?
> 
> Right, marking those two functions as __always_inline is the other
> option.  The problem is, if you keep doing it, eventually you end up
> with __always_inline-itis spreading all over the place.  And it affects
> all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> At least this fix is localized.
> 
> But I agree my patch isn't ideal either.

fwiw,
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested


thanks.
-- 
~Randy

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Randy Dunlap]

On 2/27/20 5:03 PM, Josh Poimboeuf wrote:
> On Thu, Feb 27, 2020 at 10:35:42PM +0000, Al Viro wrote:
>> On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote:
>>> With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:
>>>
>>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled
>>>
>>> This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
>>> -- and indirectly, sign_extend64() -- from the user_access_begin/end
>>> critical region (i.e, with SMAP disabled).
>>>
>>> While it's probably harmless in this case, in general we like to avoid
>>> extra function calls in SMAP-disabled regions because it can open up
>>> inadvertent security holes.
>>>
>>> Fix it by moving the gen8_canonical_addr() conversion to a separate loop
>>> before user_access_begin() is called.
>>>
>>> Note that gen8_canonical_addr() is now called *before* masking off the
>>> PIN_OFFSET_MASK bits.  That should be ok because it just does a sign
>>> extension and ignores the masked lower bits anyway.
>>
>> How painful would it be to inline the damn thing?
>> <looks>
>> static inline u64 gen8_canonical_addr(u64 address)
>> {
>>         return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
>> }
>> static inline __s64 sign_extend64(__u64 value, int index)
>> {
>>         __u8 shift = 63 - index;
>>         return (__s64)(value << shift) >> shift;
>> }
>>
>> What the hell?  Josh, what kind of .config do you have that these are
>> _not_ inlined?
> 
> I think this was seen with CONFIG_CC_OPTIMIZE_FOR_SIZE, which tends to

so the commit message correctly says.

> ignore inline.
> 
>> And why not mark gen8_canonical_addr() __always_inline?
> 
> Right, marking those two functions as __always_inline is the other
> option.  The problem is, if you keep doing it, eventually you end up
> with __always_inline-itis spreading all over the place.  And it affects
> all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> At least this fix is localized.
> 
> But I agree my patch isn't ideal either.

fwiw,
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested


thanks.
-- 
~Randy

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Patchwork]

== Series Details ==

Series: drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()
URL   : https://patchwork.freedesktop.org/series/74045/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8023 -> Patchwork_16749
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_16749:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@runner@aborted:
    - {fi-tgl-u}:         NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/fi-tgl-u/igt@runner@aborted.html

  
Known issues
------------

  Here are the changes found in Patchwork_16749 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live@perf:
    - fi-apl-guc:         [PASS][2] -> [INCOMPLETE][3] ([fdo#103927])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/fi-apl-guc/igt@i915_selftest@live@perf.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/fi-apl-guc/igt@i915_selftest@live@perf.html

  
#### Possible fixes ####

  * igt@kms_chamelium@dp-edid-read:
    - fi-cml-u2:          [FAIL][4] ([i915#217] / [i915#976]) -> [PASS][5]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976


Participating hosts (46 -> 41)
------------------------------

  Additional (3): fi-blb-e6850 fi-bdw-5557u fi-snb-2600 
  Missing    (8): fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8023 -> Patchwork_16749

  CI-20190529: 20190529
  CI_DRM_8023: fa9a02bbdfd6553ee633171f23183a115d0da577 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5474: 1be610f852de155cd915e7cda65cb2737adf04d4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16749: 6e4938bfd3cb47ed0b6c76fabbc93b7015d2a998 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6e4938bfd3cb drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

On Thu, Feb 27, 2020 at 10:26:00PM +0000, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
> >                         u64_to_user_ptr(args->buffers_ptr);
> >                 unsigned int i;
> >  
> > +               /*
> > +                * Do the call to gen8_canonical_addr() outside the
> > +                * uaccess-enabled region to minimize uaccess exposure.
> > +                */
> > +               for (i = 0; i < args->buffer_count; i++)
> > +                       exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);
> 
> 
> Another loop over all the objects, where we intentionally try and skip
> unmodified entries? To save 2 instructions from inside the second loop?
> 
> Colour me skeptical.

So are you're saying these arrays can be large and that you have
performance concerns?

-- 
Josh

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Josh Poimboeuf]

On Thu, Feb 27, 2020 at 10:26:00PM +0000, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
> >                         u64_to_user_ptr(args->buffers_ptr);
> >                 unsigned int i;
> >  
> > +               /*
> > +                * Do the call to gen8_canonical_addr() outside the
> > +                * uaccess-enabled region to minimize uaccess exposure.
> > +                */
> > +               for (i = 0; i < args->buffer_count; i++)
> > +                       exec2_list[i].offset = gen8_canonical_addr(exec2_list[i].offset);
> 
> 
> Another loop over all the objects, where we intentionally try and skip
> unmodified entries? To save 2 instructions from inside the second loop?
> 
> Colour me skeptical.

So are you're saying these arrays can be large and that you have
performance concerns?

-- 
Josh

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Peter Zijlstra]

On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote:
> > And why not mark gen8_canonical_addr() __always_inline?
> 
> Right, marking those two functions as __always_inline is the other
> option.  The problem is, if you keep doing it, eventually you end up
> with __always_inline-itis spreading all over the place.  And it affects
> all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> At least this fix is localized.

I'm all for __always_inline in this case, the compiler not inlining sign
extention is just retarded,
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Peter Zijlstra]

On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote:
> > And why not mark gen8_canonical_addr() __always_inline?
> 
> Right, marking those two functions as __always_inline is the other
> option.  The problem is, if you keep doing it, eventually you end up
> with __always_inline-itis spreading all over the place.  And it affects
> all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> At least this fix is localized.

I'm all for __always_inline in this case, the compiler not inlining sign
extention is just retarded,

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Al Viro]

On Fri, Feb 28, 2020 at 07:04:41PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote:
> > > And why not mark gen8_canonical_addr() __always_inline?
> > 
> > Right, marking those two functions as __always_inline is the other
> > option.  The problem is, if you keep doing it, eventually you end up
> > with __always_inline-itis spreading all over the place.  And it affects
> > all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> > At least this fix is localized.
> 
> I'm all for __always_inline in this case, the compiler not inlining sign
> extention is just retarded,

FWIW, in this case it's
        salq    $8, %rax
        sarq    $8, %rax
i.e. 8 bytes.  Sure, that's 3 bytes longer than call, but really, WTF?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Al Viro]

On Fri, Feb 28, 2020 at 07:04:41PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote:
> > > And why not mark gen8_canonical_addr() __always_inline?
> > 
> > Right, marking those two functions as __always_inline is the other
> > option.  The problem is, if you keep doing it, eventually you end up
> > with __always_inline-itis spreading all over the place.  And it affects
> > all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case.
> > At least this fix is localized.
> 
> I'm all for __always_inline in this case, the compiler not inlining sign
> extention is just retarded,

FWIW, in this case it's
        salq    $8, %rax
        sarq    $8, %rax
i.e. 8 bytes.  Sure, that's 3 bytes longer than call, but really, WTF?

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

[Patchwork]

== Series Details ==

Series: drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()
URL   : https://patchwork.freedesktop.org/series/74045/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8023_full -> Patchwork_16749_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

New tests
---------

  New tests have been introduced between CI_DRM_8023_full and Patchwork_16749_full:

### New IGT tests (1) ###

  * igt@kms_selftest@all:
    - Statuses :
    - Exec time: [None] s

  

Known issues
------------

  Here are the changes found in Patchwork_16749_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_persistence@close-replace-race:
    - shard-apl:          [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl2/igt@gem_ctx_persistence@close-replace-race.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-apl8/igt@gem_ctx_persistence@close-replace-race.html

  * igt@gem_exec_schedule@implicit-both-bsd1:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb4/igt@gem_exec_schedule@implicit-both-bsd1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb7/igt@gem_exec_schedule@implicit-both-bsd1.html

  * igt@gem_exec_schedule@out-order-bsd2:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#109276]) +17 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb1/igt@gem_exec_schedule@out-order-bsd2.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb6/igt@gem_exec_schedule@out-order-bsd2.html

  * igt@gem_exec_schedule@pi-userfault-bsd:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb7/igt@gem_exec_schedule@pi-userfault-bsd.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb1/igt@gem_exec_schedule@pi-userfault-bsd.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb7/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_exec_whisper@basic-queues-forked:
    - shard-glk:          [PASS][11] -> [INCOMPLETE][12] ([i915#58] / [k.org#198133])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-glk6/igt@gem_exec_whisper@basic-queues-forked.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-glk3/igt@gem_exec_whisper@basic-queues-forked.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl4/igt@gem_softpin@noreloc-s3.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-apl1/igt@gem_softpin@noreloc-s3.html

  * igt@i915_selftest@mock@buddy:
    - shard-skl:          [PASS][15] -> [INCOMPLETE][16] ([i915#1310])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl10/igt@i915_selftest@mock@buddy.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl9/igt@i915_selftest@mock@buddy.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen:
    - shard-skl:          [PASS][17] -> [FAIL][18] ([i915#54])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl3/igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen.html

  * igt@kms_hdr@bpc-switch-dpms:
    - shard-skl:          [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl8/igt@kms_hdr@bpc-switch-dpms.html

  * igt@kms_plane@plane-panning-bottom-right-pipe-c-planes:
    - shard-skl:          [PASS][21] -> [FAIL][22] ([i915#1036])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl3/igt@kms_plane@plane-panning-bottom-right-pipe-c-planes.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl2/igt@kms_plane@plane-panning-bottom-right-pipe-c-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-kbl:          [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +3 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-kbl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][25] -> [FAIL][26] ([fdo#108145] / [i915#265]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-tglb:         [PASS][27] -> [SKIP][28] ([i915#668]) +3 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-tglb1/igt@kms_psr2_su@frontbuffer.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-tglb3/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [PASS][29] -> [SKIP][30] ([fdo#109441])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html

  * igt@perf_pmu@busy-vcs1:
    - shard-iclb:         [PASS][31] -> [SKIP][32] ([fdo#112080]) +14 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb1/igt@perf_pmu@busy-vcs1.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb3/igt@perf_pmu@busy-vcs1.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
    - shard-skl:          [INCOMPLETE][33] ([i915#1197] / [i915#1239]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1:
    - shard-skl:          [FAIL][35] ([i915#679]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1.html

  * {igt@gem_ctx_ringsize@active@bcs0}:
    - shard-iclb:         [INCOMPLETE][37] ([i915#1333]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb1/igt@gem_ctx_ringsize@active@bcs0.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb2/igt@gem_ctx_ringsize@active@bcs0.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
    - shard-iclb:         [SKIP][39] ([fdo#110841]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb2/igt@gem_ctx_shared@exec-single-timeline-bsd.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb6/igt@gem_ctx_shared@exec-single-timeline-bsd.html

  * igt@gem_exec_parallel@vcs1-fds:
    - shard-iclb:         [SKIP][41] ([fdo#112080]) -> [PASS][42] +9 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb7/igt@gem_exec_parallel@vcs1-fds.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb1/igt@gem_exec_parallel@vcs1-fds.html

  * igt@gem_exec_schedule@implicit-write-read-bsd1:
    - shard-iclb:         [SKIP][43] ([fdo#109276] / [i915#677]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb8/igt@gem_exec_schedule@implicit-write-read-bsd1.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb4/igt@gem_exec_schedule@implicit-write-read-bsd1.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
    - shard-iclb:         [SKIP][45] ([i915#677]) -> [PASS][46] +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb2/igt@gem_exec_schedule@pi-shared-iova-bsd.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb5/igt@gem_exec_schedule@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
    - shard-iclb:         [SKIP][47] ([fdo#109276]) -> [PASS][48] +24 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb7/igt@gem_exec_schedule@preempt-contexts-bsd2.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb1/igt@gem_exec_schedule@preempt-contexts-bsd2.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [SKIP][49] ([fdo#112146]) -> [PASS][50] +6 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb6/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_exec_whisper@basic-contexts-forked:
    - shard-apl:          [INCOMPLETE][51] ([fdo#103927]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl2/igt@gem_exec_whisper@basic-contexts-forked.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-apl2/igt@gem_exec_whisper@basic-contexts-forked.html

  * igt@gem_userptr_blits@sync-unmap-after-close:
    - shard-glk:          [DMESG-WARN][53] ([fdo#111870] / [i915#836]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-glk1/igt@gem_userptr_blits@sync-unmap-after-close.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-glk1/igt@gem_userptr_blits@sync-unmap-after-close.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          [DMESG-WARN][55] ([i915#180]) -> [PASS][56] +3 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl6/igt@gem_workarounds@suspend-resume-context.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-apl8/igt@gem_workarounds@suspend-resume-context.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [INCOMPLETE][57] -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb2/igt@i915_pm_dc@dc6-dpms.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb8/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-onscreen:
    - shard-skl:          [FAIL][59] ([i915#54]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-256x85-onscreen.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-256x85-onscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding:
    - shard-apl:          [FAIL][61] ([i915#54]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-apl8/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [FAIL][63] ([i915#46]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl10/igt@kms_flip@flip-vs-expired-vblank.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-skl3/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][65] ([i915#180]) -> [PASS][66] +3 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [SKIP][67] ([fdo#109642] / [fdo#111068]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb5/igt@kms_psr2_su@frontbuffer.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb2/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_setmode@basic:
    - shard-hsw:          [FAIL][69] ([i915#31]) -> [PASS][70]
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-hsw1/igt@kms_setmode@basic.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-hsw4/igt@kms_setmode@basic.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv-switch:
    - shard-iclb:         [SKIP][71] ([fdo#112080]) -> [FAIL][72] ([IGT#28])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb5/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html

  * igt@i915_selftest@live@gt_lrc:
    - shard-tglb:         [DMESG-FAIL][73] ([i915#1233]) -> [INCOMPLETE][74] ([i915#1233])
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-tglb1/igt@i915_selftest@live@gt_lrc.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/shard-tglb7/igt@i915_selftest@live@gt_lrc.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [i915#1036]: https://gitlab.freedesktop.org/drm/intel/issues/1036
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
  [i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
  [i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
  [i915#1310]: https://gitlab.freedesktop.org/drm/intel/issues/1310
  [i915#1333]: https://gitlab.freedesktop.org/drm/intel/issues/1333
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
  [i915#46]: https://gitlab.freedesktop.org/drm/intel/issues/46
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
  [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
  [i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
  [i915#836]: https://gitlab.freedesktop.org/drm/intel/issues/836
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8023 -> Patchwork_16749

  CI-20190529: 20190529
  CI_DRM_8023: fa9a02bbdfd6553ee633171f23183a115d0da577 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5474: 1be610f852de155cd915e7cda65cb2737adf04d4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16749: 6e4938bfd3cb47ed0b6c76fabbc93b7015d2a998 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16749/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx