[PATCH 1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[PATCH 1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Chris Wilson]

As kmalloc is allowed to block (if given the right flags), mark up the
two i915_sw_fence routines that may call kmalloc as potential sleeping
routines.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c
index e8ca67a129d2..1212b04604be 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -303,6 +303,7 @@ static int __i915_sw_fence_await_sw_fence(struct i915_sw_fence *fence,
 	int pending;
 
 	debug_fence_assert(fence);
+	might_sleep_if(gfpflags_allow_blocking(gfp));
 
 	if (i915_sw_fence_done(signaler))
 		return 0;
@@ -418,6 +419,7 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence *fence,
 	int ret;
 
 	debug_fence_assert(fence);
+	might_sleep_if(gfpflags_allow_blocking(gfp));
 
 	if (dma_fence_is_signaled(dma))
 		return 0;
@@ -464,6 +466,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
 	int ret = 0, pending;
 
 	debug_fence_assert(fence);
+	might_sleep_if(gfpflags_allow_blocking(gfp));
 
 	if (write) {
 		struct dma_fence **shared;
-- 
2.15.1

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

[PATCH 2/3] drm/i915: Allow fence allocations to fail

[Chris Wilson]

If a fence allocation fails in a blocking context, we will sleep on the
fence as a last resort. We can therefore allow ourselves to fail and
sleep on the fence instead of triggering a system-wide oom. This allows
us to throttle malicious clients that are consuming lots of system
resources by capping the amount of memory used by fences.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_clflush.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_request.c | 6 +++---
 drivers/gpu/drm/i915/i915_gem_request.h | 2 ++
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c b/drivers/gpu/drm/i915/i915_gem_clflush.c
index f663cd919795..b9b53ac14176 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -167,7 +167,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 		i915_sw_fence_await_reservation(&clflush->wait,
 						obj->resv, NULL,
 						true, I915_FENCE_TIMEOUT,
-						GFP_KERNEL);
+						I915_FENCE_GFP);
 
 		reservation_object_lock(obj->resv, NULL);
 		reservation_object_add_excl_fence(obj->resv, &clflush->dma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 21ce374d9924..648e7536ff51 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -617,7 +617,7 @@ int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv)
 			if (prev)
 				i915_sw_fence_await_sw_fence_gfp(&req->submit,
 								 &prev->submit,
-								 GFP_KERNEL);
+								 I915_FENCE_GFP);
 		}
 
 		/*
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
index c28a4ceb016d..4d5e2b714382 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -782,7 +782,7 @@ i915_gem_request_await_request(struct drm_i915_gem_request *to,
 	if (to->engine == from->engine) {
 		ret = i915_sw_fence_await_sw_fence_gfp(&to->submit,
 						       &from->submit,
-						       GFP_KERNEL);
+						       I915_FENCE_GFP);
 		return ret < 0 ? ret : 0;
 	}
 
@@ -810,7 +810,7 @@ i915_gem_request_await_request(struct drm_i915_gem_request *to,
 await_dma_fence:
 	ret = i915_sw_fence_await_dma_fence(&to->submit,
 					    &from->fence, 0,
-					    GFP_KERNEL);
+					    I915_FENCE_GFP);
 	return ret < 0 ? ret : 0;
 }
 
@@ -861,7 +861,7 @@ i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
 		else
 			ret = i915_sw_fence_await_dma_fence(&req->submit, fence,
 							    I915_FENCE_TIMEOUT,
-							    GFP_KERNEL);
+							    I915_FENCE_GFP);
 		if (ret < 0)
 			return ret;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h
index 26249f39de67..0d6d39f19506 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -204,6 +204,8 @@ struct drm_i915_gem_request {
 	struct list_head client_link;
 };
 
+#define I915_FENCE_GFP (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
+
 extern const struct dma_fence_ops i915_fence_ops;
 
 static inline bool dma_fence_is_i915(const struct dma_fence *fence)
-- 
2.15.1

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

[PATCH 3/3] drm/i915: Ratelimit request allocation under oom

[Chris Wilson]

If we fail to allocate a request, we can reap the outstanding requests
and push them to the request's slab's freelist before trying again. This
forces us to ratelimit malicious clients that tie up all of the system
resources in requests, instead of causing a system-wide oom.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_request.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
index 4d5e2b714382..59f023bb7015 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -677,10 +677,21 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 	 *
 	 * Do not use kmem_cache_zalloc() here!
 	 */
-	req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
-	if (!req) {
-		ret = -ENOMEM;
-		goto err_unreserve;
+	req = kmem_cache_alloc(dev_priv->requests,
+			       GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+	if (unlikely(!req)) {
+		/* Ratelimit ourselves to prevent oom from malicious clients */
+		ret = i915_gem_wait_for_idle(dev_priv,
+					     I915_WAIT_LOCKED |
+					     I915_WAIT_INTERRUPTIBLE);
+		if (ret)
+			goto err_unreserve;
+
+		req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
+		if (!req) {
+			ret = -ENOMEM;
+			goto err_unreserve;
+		}
 	}
 
 	req->timeline = i915_gem_context_lookup_timeline(ctx, engine);
-- 
2.15.1

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

✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep
URL   : https://patchwork.freedesktop.org/series/35239/
State : success

== Summary ==

Series 35239v1 series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep
https://patchwork.freedesktop.org/api/1.0/series/35239/revisions/1/mbox/

Test gem_exec_suspend:
        Subgroup basic-s3:
                incomplete -> PASS       (fi-glk-1) fdo#103326
Test gem_mmap_gtt:
        Subgroup basic-small-bo-tiledx:
                pass       -> FAIL       (fi-gdg-551) fdo#102575

fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:440s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:447s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:385s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:511s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:280s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:506s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:509s
fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:491s
fi-elk-e7500     total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551       total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 time:271s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:532s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:359s
fi-hsw-4770r     total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  time:261s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:392s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:481s
fi-ivb-3770      total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:447s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:482s
fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:525s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:474s
fi-kbl-r         total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  time:529s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:588s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:455s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:538s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:571s
fi-skl-6700k     total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:526s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:499s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:454s
fi-snb-2520m     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:549s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:418s
Blacklisted hosts:
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:609s
fi-cnl-y         total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:641s
fi-byt-n2820 failed to collect. IGT log at Patchwork_7475/fi-byt-n2820/igt.log

f49a92217adcf7e3c219b6b9ea57b33c917c6a13 drm-tip: 2017y-12m-12d-12h-12m-26s UTC integration manifest
c77ea212e0c6 drm/i915: Ratelimit request allocation under oom
4841ec7fcc28 drm/i915: Allow fence allocations to fail
ec41da59d603 drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

== Logs ==

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

✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep
URL   : https://patchwork.freedesktop.org/series/35239/
State : success

== Summary ==

Test gem_tiled_swapping:
        Subgroup non-threaded:
                incomplete -> PASS       (shard-snb) fdo#104009
                pass       -> INCOMPLETE (shard-hsw) fdo#104218
Test kms_flip:
        Subgroup plain-flip-fb-recreate-interruptible:
                pass       -> FAIL       (shard-hsw) fdo#100368
Test kms_cursor_crc:
        Subgroup cursor-256x256-suspend:
                pass       -> DMESG-WARN (shard-snb) fdo#103375

fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-hsw        total:2681 pass:1517 dwarn:1   dfail:0   fail:11  skip:1151 time:9133s
shard-snb        total:2712 pass:1309 dwarn:2   dfail:0   fail:11  skip:1390 time:8111s
Blacklisted hosts:
shard-apl        total:2690 pass:1666 dwarn:1   dfail:0   fail:21  skip:1001 time:13508s
shard-kbl        total:2656 pass:1768 dwarn:1   dfail:0   fail:22  skip:864 time:10730s

== Logs ==

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

Re: [PATCH 1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Joonas Lahtinen]

On Tue, 2017-12-12 at 18:06 +0000, Chris Wilson wrote:
> As kmalloc is allowed to block (if given the right flags), mark up the
> two i915_sw_fence routines that may call kmalloc as potential sleeping
> routines.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] drm/i915: Allow fence allocations to fail

[Joonas Lahtinen]

On Tue, 2017-12-12 at 18:06 +0000, Chris Wilson wrote:
> If a fence allocation fails in a blocking context, we will sleep on the
> fence as a last resort. We can therefore allow ourselves to fail and
> sleep on the fence instead of triggering a system-wide oom. This allows
> us to throttle malicious clients that are consuming lots of system
> resources by capping the amount of memory used by fences.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Claim checks out,

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/3] drm/i915: Ratelimit request allocation under oom

[Joonas Lahtinen]

On Tue, 2017-12-12 at 18:06 +0000, Chris Wilson wrote:
> If we fail to allocate a request, we can reap the outstanding requests
> and push them to the request's slab's freelist before trying again. This
> forces us to ratelimit malicious clients that tie up all of the system
> resources in requests, instead of causing a system-wide oom.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Maybe throw a Testcase: here?

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/3] drm/i915: Ratelimit request allocation under oom

[Chris Wilson]

Quoting Joonas Lahtinen (2017-12-13 11:18:42)
> On Tue, 2017-12-12 at 18:06 +0000, Chris Wilson wrote:
> > If we fail to allocate a request, we can reap the outstanding requests
> > and push them to the request's slab's freelist before trying again. This
> > forces us to ratelimit malicious clients that tie up all of the system
> > resources in requests, instead of causing a system-wide oom.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> 
> Maybe throw a Testcase: here?

Testcase: igt/gem_shrink/execbuf1
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] drm/i915: Allow fence allocations to fail

[Chris Wilson]

Quoting Joonas Lahtinen (2017-12-13 11:15:23)
> On Tue, 2017-12-12 at 18:06 +0000, Chris Wilson wrote:
> > If a fence allocation fails in a blocking context, we will sleep on the
> > fence as a last resort. We can therefore allow ourselves to fail and
> > sleep on the fence instead of triggering a system-wide oom. This allows
> > us to throttle malicious clients that are consuming lots of system
> > resources by capping the amount of memory used by fences.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> 
> Claim checks out,
> 
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Testcase: igt/gem_shrink/execbufX
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Chris Wilson]

Quoting Patchwork (2017-12-12 19:20:00)
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep
> URL   : https://patchwork.freedesktop.org/series/35239/
> State : success
> 
> == Summary ==
> 
> Test gem_tiled_swapping:
>         Subgroup non-threaded:
>                 incomplete -> PASS       (shard-snb) fdo#104009
>                 pass       -> INCOMPLETE (shard-hsw) fdo#104218
> Test kms_flip:
>         Subgroup plain-flip-fb-recreate-interruptible:
>                 pass       -> FAIL       (shard-hsw) fdo#100368
> Test kms_cursor_crc:
>         Subgroup cursor-256x256-suspend:
>                 pass       -> DMESG-WARN (shard-snb) fdo#103375

Thanks for the review. Having left a bit of clear air on CI after the
associated fixes, now pushed.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx