Message ID | 1417521594-3437-1-git-send-email-thellstrom@vmware.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 2 December 2014 at 21:59, Thomas Hellstrom <thellstrom@vmware.com> wrote: > Kernel side fence objects are used when unbinding resources and may thus be > created as part of a memory reclaim operation. This might trigger recursive > memory reclaims and result in the kernel running out of stack space. > > So a simple way out is to avoid accounting of these fence objects. > In principle this is OK since while user-space can trigger the creation of > such objects, it can't really hold on to them. However, their lifetime is > quite long, so some form of accounting should perhaps be implemented in the > future. > > Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 > with low system memory settings. are these 3 intended for fixes? can you send me a git pull for them soon, so they don't miss Linus release. Dave.
On 12/03/2014 02:06 AM, Dave Airlie wrote: > On 2 December 2014 at 21:59, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> Kernel side fence objects are used when unbinding resources and may thus be >> created as part of a memory reclaim operation. This might trigger recursive >> memory reclaims and result in the kernel running out of stack space. >> >> So a simple way out is to avoid accounting of these fence objects. >> In principle this is OK since while user-space can trigger the creation of >> such objects, it can't really hold on to them. However, their lifetime is >> quite long, so some form of accounting should perhaps be implemented in the >> future. >> >> Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 >> with low system memory settings. > are these 3 intended for fixes? can you send me a git pull for them > soon, so they don't miss Linus release. > > Dave. Hi. Actually, these bugs have been quite long-standing and I feel a bit uncomfortable including the fixes this late in the release cycle. I'd rather wait to 3.19 unless you think otherwise. Thanks, Thomas
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 197164f..6773938 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -545,35 +545,19 @@ void vmw_fence_obj_flush(struct vmw_fence_obj *fence) static void vmw_fence_destroy(struct vmw_fence_obj *fence) { - struct vmw_fence_manager *fman = fman_from_fence(fence); - fence_free(&fence->base); - - /* - * Free kernel space accounting. - */ - ttm_mem_global_free(vmw_mem_glob(fman->dev_priv), - fman->fence_size); } int vmw_fence_create(struct vmw_fence_manager *fman, uint32_t seqno, struct vmw_fence_obj **p_fence) { - struct ttm_mem_global *mem_glob = vmw_mem_glob(fman->dev_priv); struct vmw_fence_obj *fence; int ret; - ret = ttm_mem_global_alloc(mem_glob, fman->fence_size, - false, false); - if (unlikely(ret != 0)) - return ret; - fence = kzalloc(sizeof(*fence), GFP_KERNEL); - if (unlikely(fence == NULL)) { - ret = -ENOMEM; - goto out_no_object; - } + if (unlikely(fence == NULL)) + return -ENOMEM; ret = vmw_fence_obj_init(fman, fence, seqno, vmw_fence_destroy); @@ -585,8 +569,6 @@ int vmw_fence_create(struct vmw_fence_manager *fman, out_err_init: kfree(fence); -out_no_object: - ttm_mem_global_free(mem_glob, fman->fence_size); return ret; }