dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] drm/amd/amdkfd: fix possible memory leak in svm_range_restore_pages
by Xiyu Yang 09 Sep '21

09 Sep '21

The memory leak issue may take place in an error handling path. When p->xnack_enabled is NULL, the function simply returns with -EFAULT and forgets to decrement the reference count of a kfd_process object bumped by kfd_lookup_process_by_pasid, which may incur memory leaks. Fix it by jumping to label "out", in which kfd_unref_process() decreases the refcount. Signed-off-by: Xiyu Yang <xiyuyang19(a)fudan.edu.cn> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index e883731c3f8f..0f7f1e5621ea 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2426,7 +2426,8 @@ svm_range_restore_pages(struct amdgpu_device *adev, unsigned int pasid, } if (!p->xnack_enabled) { pr_debug("XNACK not enabled for pasid 0x%x\n", pasid); - return -EFAULT; + r = -EFAULT; + goto out; } svms = &p->svms; -- 2.7.4

2 1

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration
by Felix Kuehling 09 Sep '21

09 Sep '21

Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig: > On Mon, Aug 30, 2021 at 01:04:43PM -0400, Felix Kuehling wrote: >>>> driver code is not really involved in updating the CPU mappings. Maybe >>>> it's something we need to do in the migration helpers. >>> It looks like I'm totally misunderstanding what you are adding here >>> then. Why do we need any special treatment at all for memory that >>> has normal struct pages and is part of the direct kernel map? >> The pages are like normal memory for purposes of mapping them in CPU >> page tables and for coherent access from the CPU. > That's the user page tables. What about the kernel direct map? > If there is a normal kernel struct page backing there really should > be no need for the pgmap. I'm not sure. The physical address ranges are in the UEFI system address map as special-purpose memory. Does Linux create the struct pages and kernel direct map for that without a pgmap call? I didn't see that last time I went digging through that code. > >> From an application >> perspective, we want file-backed and anonymous mappings to be able to >> use DEVICE_PUBLIC pages with coherent CPU access. The goal is to >> optimize performance for GPU heavy workloads while minimizing the need >> to migrate data back-and-forth between system memory and device memory. > I don't really understand that part. file backed pages are always > allocated by the file system using the pagecache helpers, that is > using the page allocator. Anonymouns memory also always comes from > the page allocator. I'm coming at this from my experience with DEVICE_PRIVATE. Both anonymous and file-backed pages should be migrateable to DEVICE_PRIVATE memory by the migrate_vma_* helpers for more efficient access by our GPU. (*) It's part of the basic premise of HMM as I understand it. I would expect the same thing to work for DEVICE_PUBLIC memory. (*) I believe migrating file-backed pages to DEVICE_PRIVATE doesn't currently work, but that's something I'm hoping to fix at some point. > >> The pages are special in two ways: >> >> 1. The memory is managed not by the Linux buddy allocator, but by the >> GPU driver's TTM memory manager > Why? It's a system architectural decision based on the access latency to the memory and the expected use cases that we do not want the GPU driver and the Linux buddy allocator and VM subsystem competing for the same device memory. > >> 2. We want to migrate data in response to GPU page faults and >> application hints using the migrate_vma helpers > Why? Device memory has much higher bandwidth and much lower latency than regular system memory for the GPU to access. It's essential for enabling good GPU application performance. Page-based memory migration enables good performance with more intuitive programming models such as managed/unified memory in HIP or unified shared memory in OpenMP. We do this on our discrete GPUs with DEVICE_PRIVATE memory. I see DEVICE_PUBLIC as an improved version of DEVICE_PRIVATE that allows the CPU to map the device memory coherently to minimize the need for migrations when CPU and GPU access the same memory concurrently or alternatingly. But we're not going as far as putting that memory entirely under the management of the Linux memory manager and VM subsystem. Our (and HPE's) system architects decided that this memory is not suitable to be used like regular NUMA system memory by the Linux memory manager. Regards, Felix

2 4

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration
by Felix Kuehling 09 Sep '21

09 Sep '21

Am 2021-09-02 um 4:18 a.m. schrieb Christoph Hellwig: > On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote: >>>>> It looks like I'm totally misunderstanding what you are adding here >>>>> then. Why do we need any special treatment at all for memory that >>>>> has normal struct pages and is part of the direct kernel map? >>>> The pages are like normal memory for purposes of mapping them in CPU >>>> page tables and for coherent access from the CPU. >>> That's the user page tables. What about the kernel direct map? >>> If there is a normal kernel struct page backing there really should >>> be no need for the pgmap. >> I'm not sure. The physical address ranges are in the UEFI system address >> map as special-purpose memory. Does Linux create the struct pages and >> kernel direct map for that without a pgmap call? I didn't see that last >> time I went digging through that code. > So doing some googling finds a patch from Dan that claims to hand EFI > special purpose memory to the device dax driver. But when I try to > follow the version that got merged it looks it is treated simply as an > MMIO region to be claimed by drivers, which would not get a struct page. > > Dan, did I misunderstand how E820_TYPE_SOFT_RESERVED works? > >>>> From an application >>>> perspective, we want file-backed and anonymous mappings to be able to >>>> use DEVICE_PUBLIC pages with coherent CPU access. The goal is to >>>> optimize performance for GPU heavy workloads while minimizing the need >>>> to migrate data back-and-forth between system memory and device memory. >>> I don't really understand that part. file backed pages are always >>> allocated by the file system using the pagecache helpers, that is >>> using the page allocator. Anonymouns memory also always comes from >>> the page allocator. >> I'm coming at this from my experience with DEVICE_PRIVATE. Both >> anonymous and file-backed pages should be migrateable to DEVICE_PRIVATE >> memory by the migrate_vma_* helpers for more efficient access by our >> GPU. (*) It's part of the basic premise of HMM as I understand it. I >> would expect the same thing to work for DEVICE_PUBLIC memory. > Ok, so you want to migrate to and from them. Not use DEVICE_PUBLIC > for the actual page cache pages. That maks a lot more sense. > >> I see DEVICE_PUBLIC as an improved version of DEVICE_PRIVATE that allows >> the CPU to map the device memory coherently to minimize the need for >> migrations when CPU and GPU access the same memory concurrently or >> alternatingly. But we're not going as far as putting that memory >> entirely under the management of the Linux memory manager and VM >> subsystem. Our (and HPE's) system architects decided that this memory is >> not suitable to be used like regular NUMA system memory by the Linux >> memory manager. > So yes. It is a Memory Mapped I/O region, which unlike the PCIe BARs > that people typically deal with is fully cache coherent. I think this > does make more sense as a description. > > But to go back to what start this discussion: If these are memory > mapped I/O pfn_valid should generally not return true for them. As I understand it, pfn_valid should be true for any pfn that's part of the kernel's physical memory map, i.e. is returned by page_to_pfn or works with pfn_to_page. Both the hmm_range_fault and the migrate_vma_* APIs use pfns to refer to regular system memory and ZONE_DEVICE pages (even DEVICE_PRIVATE). Therefore I believe pfn_valid should be true for ZONE_DEVICE pages as well. Regards, Felix > > And as you already pointed out in reply to Alex we need to tighten the > selection criteria one way or another.

1 0

[PATCH v5 00/25] Clean up GuC CI failures, simplify locking, and kernel DOC
by Daniele Ceraolo Spurio 08 Sep '21

08 Sep '21

Daniel Vetter pointed out that locking in the GuC submission code was overly complicated, let's clean this up a bit before introducing more features in the GuC submission backend. Also fix some CI failures, port fixes from our internal tree, and add a few more selftests for coverage. Lastly, add some kernel DOC explaining how the GuC submission backend works. v2: Fix logic error in 'Workaround reset G2H is received after schedule done G2H', don't propagate errors to dependent fences in execlists submissiom, resolve checkpatch issues, resend to correct lists v3: Fix issue kicking tasklet, drop guc_active, fix ref counting in xarray, add guc_id sub structure, drop inline fuctions, and various other cleanup suggested by Daniel v4: Address Daniele's feedback, rebase to tip, resend for CI v5 [Daniele taking over while Matt is out]: drop patches 8 and 27 for now (not critical, Matt will update and resend when he's back), address review comments, improve kerneldoc. Also move all code related to busy loop to patch 2 so we have a standalone fix. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> #v5 Matthew Brost (25): drm/i915/guc: Fix blocked context accounting drm/i915/guc: Fix outstanding G2H accounting drm/i915/guc: Unwind context requests in reverse order drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context drm/i915/guc: Process all G2H message at once in work queue drm/i915/guc: Workaround reset G2H is received after schedule done G2H Revert "drm/i915/gt: Propagate change in error status to children on unhold" drm/i915/guc: Kick tasklet after queuing a request drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered drm/i915/guc: Copy whole golden context, set engine state size of subset drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drm/i915/guc: Take context ref when cancelling request drm/i915/guc: Don't touch guc_state.sched_state without a lock drm/i915/guc: Reset LRC descriptor if register returns -ENODEV drm/i915: Allocate error capture in nowait context drm/i915/guc: Flush G2H work queue during reset drm/i915/guc: Release submit fence from an irq_work drm/i915/guc: Move guc_blocked fence to struct guc_state drm/i915/guc: Rework and simplify locking drm/i915/guc: Proper xarray usage for contexts_lookup drm/i915/guc: Drop pin count check trick between sched_disable and re-pin drm/i915/guc: Move GuC priority fields in context under guc_active drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure drm/i915/guc: Drop guc_active move everything into guc_state drm/i915/guc: Add GuC kernel doc Documentation/gpu/i915.rst | 2 + drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 80 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 68 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 921 +++++++++++------- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 127 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 39 +- drivers/gpu/drm/i915/i915_request.h | 26 +- drivers/gpu/drm/i915/i915_trace.h | 12 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + .../i915/selftests/intel_scheduler_helpers.c | 12 + .../i915/selftests/intel_scheduler_helpers.h | 2 + 16 files changed, 884 insertions(+), 467 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.25.1

2 32

[drm:i915-uncore-vfunc 30/31] drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: implicit declaration of function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; did you mean 'MMIO_RAW_WRITE_VFUNCS'?
by kernel test robot 08 Sep '21

08 Sep '21

tree: git://people.freedesktop.org/~airlied/linux.git i915-uncore-vfunc head: b42168f90718a955550b11f2d52306d9aeaa9468 commit: 99aebd17891290abfca80c48eca01f4e02413fb3 [30/31] drm/i915/uncore: constify the register vtables. config: i386-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): git remote add drm git://people.freedesktop.org/~airlied/linux.git git fetch --no-tags drm i915-uncore-vfunc git checkout 99aebd17891290abfca80c48eca01f4e02413fb3 # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/intel_uncore.c:2630: drivers/gpu/drm/i915/selftests/mock_uncore.c: In function 'mock_uncore_init': >> drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: implicit declaration of function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; did you mean 'MMIO_RAW_WRITE_VFUNCS'? [-Werror=implicit-function-declaration] 47 | ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | MMIO_RAW_WRITE_VFUNCS >> drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: 'nop' undeclared (first use in this function); did you mean 'nopv'? 47 | ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop); | ^~~ | nopv drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: note: each undeclared identifier is reported only once for each function it appears in >> drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: implicit declaration of function 'ASSIGN_RAW_READ_MMIO_VFUNCS' [-Werror=implicit-function-declaration] 48 | ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ At top level: >> drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: error: 'nop_read64' defined but not used [-Werror=unused-function] 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: note: in definition of macro '__nop_read' 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: error: 'nop_read32' defined but not used [-Werror=unused-function] 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: note: in definition of macro '__nop_read' 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: error: 'nop_read16' defined but not used [-Werror=unused-function] 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: note: in definition of macro '__nop_read' 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: error: 'nop_read8' defined but not used [-Werror=unused-function] 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:36:1: note: in definition of macro '__nop_read' 36 | nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } | ^~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: error: 'nop_write32' defined but not used [-Werror=unused-function] 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: note: in definition of macro '__nop_write' 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: error: 'nop_write16' defined but not used [-Werror=unused-function] 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: note: in definition of macro '__nop_write' 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ >> drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: error: 'nop_write8' defined but not used [-Werror=unused-function] 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ drivers/gpu/drm/i915/selftests/mock_uncore.c:29:1: note: in definition of macro '__nop_write' 29 | nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } | ^~~~~~~~~ cc1: all warnings being treated as errors vim +47 drivers/gpu/drm/i915/selftests/mock_uncore.c 0757ac8fc7c1da Chris Wilson 2017-04-12 26 0757ac8fc7c1da Chris Wilson 2017-04-12 27 #define __nop_write(x) \ 0757ac8fc7c1da Chris Wilson 2017-04-12 28 static void \ a2b4abfc626b13 Daniele Ceraolo Spurio 2019-03-25 @29 nop_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { } 0757ac8fc7c1da Chris Wilson 2017-04-12 30 __nop_write(8) 0757ac8fc7c1da Chris Wilson 2017-04-12 31 __nop_write(16) 0757ac8fc7c1da Chris Wilson 2017-04-12 32 __nop_write(32) 0757ac8fc7c1da Chris Wilson 2017-04-12 33 0757ac8fc7c1da Chris Wilson 2017-04-12 34 #define __nop_read(x) \ 0757ac8fc7c1da Chris Wilson 2017-04-12 35 static u##x \ a2b4abfc626b13 Daniele Ceraolo Spurio 2019-03-25 @36 nop_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { return 0; } 0757ac8fc7c1da Chris Wilson 2017-04-12 37 __nop_read(8) 0757ac8fc7c1da Chris Wilson 2017-04-12 38 __nop_read(16) 0757ac8fc7c1da Chris Wilson 2017-04-12 39 __nop_read(32) 0757ac8fc7c1da Chris Wilson 2017-04-12 40 __nop_read(64) 0757ac8fc7c1da Chris Wilson 2017-04-12 41 d14a701b007063 Chris Wilson 2019-10-08 42 void mock_uncore_init(struct intel_uncore *uncore, d14a701b007063 Chris Wilson 2019-10-08 43 struct drm_i915_private *i915) 0757ac8fc7c1da Chris Wilson 2017-04-12 44 { d14a701b007063 Chris Wilson 2019-10-08 45 intel_uncore_init_early(uncore, i915); d14a701b007063 Chris Wilson 2019-10-08 46 ccb2aceaaa5f92 Daniele Ceraolo Spurio 2019-06-19 @47 ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop); ccb2aceaaa5f92 Daniele Ceraolo Spurio 2019-06-19 @48 ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop); :::::: The code at line 47 was first introduced by commit :::::: ccb2aceaaa5f9267ef7b485b41ae9be3f04b50d3 drm/i915: use vfuncs for reg_read/write_fw_domains :::::: TO: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> :::::: CC: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[PATCH] drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV
by Guenter Roeck 08 Sep '21

08 Sep '21

nvkm test builds fail with the following error. drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info': drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5' The code builds on most architectures, but fails on parisc where ENOSYS is defined as 251. Replace the error code with -ENODEV (-19). The actual error code does not really matter and is not passed to userspace - it just has to be negative. Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in sysfs") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c index b0ece71aefde..ce774579c89d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c @@ -57,7 +57,7 @@ nvkm_control_mthd_pstate_info(struct nvkm_control *ctrl, void *data, u32 size) args->v0.count = 0; args->v0.ustate_ac = NVIF_CONTROL_PSTATE_INFO_V0_USTATE_DISABLE; args->v0.ustate_dc = NVIF_CONTROL_PSTATE_INFO_V0_USTATE_DISABLE; - args->v0.pwrsrc = -ENOSYS; + args->v0.pwrsrc = -ENODEV; args->v0.pstate = NVIF_CONTROL_PSTATE_INFO_V0_PSTATE_UNKNOWN; } -- 2.33.0

1 0

[PATCH] drm/sched: Fix drm_sched_fence_free() so it can be passed an uninitialized fence
by Boris Brezillon 08 Sep '21

08 Sep '21

drm_sched_job_cleanup() will pass an uninitialized fence to drm_sched_fence_free(), which will cause to_drm_sched_fence() to return a NULL fence object, causing a NULL pointer deref when this NULL object is passed to kmem_cache_free(). Let's create a new drm_sched_fence_free() function that takes a drm_sched_fence pointer and suffix the old function with _rcu. While at it, complain if drm_sched_fence_free() is passed an initialized fence or if drm_sched_fence_free_rcu() is passed an uninitialized fence. Fixes: dbe48d030b28 ("drm/sched: Split drm_sched_job_init") Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- Found while debugging another issue in panfrost causing a failure in the submit ioctl and exercising the error path (path that calls drm_sched_job_cleanup() on an unarmed job). --- drivers/gpu/drm/scheduler/sched_fence.c | 29 ++++++++++++++++--------- drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/gpu_scheduler.h | 2 +- 3 files changed, 21 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c index db3fd1303fc4..7fd869520ef2 100644 --- a/drivers/gpu/drm/scheduler/sched_fence.c +++ b/drivers/gpu/drm/scheduler/sched_fence.c @@ -69,19 +69,28 @@ static const char *drm_sched_fence_get_timeline_name(struct dma_fence *f) return (const char *)fence->sched->name; } -/** - * drm_sched_fence_free - free up the fence memory - * - * @rcu: RCU callback head - * - * Free up the fence memory after the RCU grace period. - */ -void drm_sched_fence_free(struct rcu_head *rcu) +static void drm_sched_fence_free_rcu(struct rcu_head *rcu) { struct dma_fence *f = container_of(rcu, struct dma_fence, rcu); struct drm_sched_fence *fence = to_drm_sched_fence(f); - kmem_cache_free(sched_fence_slab, fence); + if (!WARN_ON_ONCE(!fence)) + kmem_cache_free(sched_fence_slab, fence); +} + +/** + * drm_sched_fence_free - free up an uninitialized fence + * + * @fence: fence to free + * + * Free up the fence memory. Should only be used if drm_sched_fence_init() + * has not been called yet. + */ +void drm_sched_fence_free(struct drm_sched_fence *fence) +{ + /* This function should not be called if the fence has been initialized. */ + if (!WARN_ON_ONCE(fence->sched)) + kmem_cache_free(sched_fence_slab, fence); } /** @@ -97,7 +106,7 @@ static void drm_sched_fence_release_scheduled(struct dma_fence *f) struct drm_sched_fence *fence = to_drm_sched_fence(f); dma_fence_put(fence->parent); - call_rcu(&fence->finished.rcu, drm_sched_fence_free); + call_rcu(&fence->finished.rcu, drm_sched_fence_free_rcu); } /** diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index fbbd3b03902f..6987d412a946 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -750,7 +750,7 @@ void drm_sched_job_cleanup(struct drm_sched_job *job) dma_fence_put(&job->s_fence->finished); } else { /* aborted job before committing to run it */ - drm_sched_fence_free(&job->s_fence->finished.rcu); + drm_sched_fence_free(job->s_fence); } job->s_fence = NULL; diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h index 7f77a455722c..f011e4c407f2 100644 --- a/include/drm/gpu_scheduler.h +++ b/include/drm/gpu_scheduler.h @@ -509,7 +509,7 @@ struct drm_sched_fence *drm_sched_fence_alloc( struct drm_sched_entity *s_entity, void *owner); void drm_sched_fence_init(struct drm_sched_fence *fence, struct drm_sched_entity *entity); -void drm_sched_fence_free(struct rcu_head *rcu); +void drm_sched_fence_free(struct drm_sched_fence *fence); void drm_sched_fence_scheduled(struct drm_sched_fence *fence); void drm_sched_fence_finished(struct drm_sched_fence *fence); -- 2.31.1

2 1

[PATCH][next] drm/i915: clean up inconsistent indenting
by Colin King 08 Sep '21

08 Sep '21

From: Colin Ian King <colin.king(a)canonical.com> There is a statement that is indented one character too deeply, clean this up. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index de5f9c86b9a4..aeb324b701ec 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -2565,7 +2565,7 @@ __execlists_context_pre_pin(struct intel_context *ce, if (!__test_and_set_bit(CONTEXT_INIT_BIT, &ce->flags)) { lrc_init_state(ce, engine, *vaddr); - __i915_gem_object_flush_map(ce->state->obj, 0, engine->context_size); + __i915_gem_object_flush_map(ce->state->obj, 0, engine->context_size); } return 0; -- 2.32.0

2 1

[PATCH] drm/ttm: provide default page protection for UML
by Randy Dunlap 08 Sep '21

08 Sep '21

boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct member named 'x86', so provide a default page protection mode for CONFIG_UML. Mends this build error: ../drivers/gpu/drm/ttm/ttm_module.c: In function ‘ttm_prot_from_caching’: ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct cpuinfo_um’ has no member named ‘x86’ else if (boot_cpu_data.x86 > 3) ^ Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: Jeff Dike <jdike(a)addtoit.com> Cc: Richard Weinberger <richard(a)nod.at> Cc: Anton Ivanov <anton.ivanov(a)cambridgegreys.com> Cc: linux-um(a)lists.infradead.org Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/ttm/ttm_module.c | 4 ++++ 1 file changed, 4 insertions(+) --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_ if (caching == ttm_cached) return tmp; +#ifdef CONFIG_UML + tmp = pgprot_noncached(tmp); +#else #if defined(__i386__) || defined(__x86_64__) if (caching == ttm_write_combined) tmp = pgprot_writecombine(tmp); @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_ #if defined(__sparc__) tmp = pgprot_noncached(tmp); #endif +#endif return tmp; }

6 10

[syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect
by syzbot 08 Sep '21

08 Sep '21

Hello, syzbot found the following issue on: HEAD commit: 3dbdb38e Merge branch 'for-5.14' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1323c402300000 kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757 dashboard link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f0e772300000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1114b9b0300000 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10fa45d8300000 final oops: https://syzkaller.appspot.com/x/report.txt?x=12fa45d8300000 console output: https://syzkaller.appspot.com/x/log.txt?x=14fa45d8300000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+04168c8063cfdde1db5e(a)syzkaller.appspotmail.com BUG: unable to handle page fault for address: ffff888001000050 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 10e01067 P4D 10e01067 PUD 10e02067 PMD 80000000010001e1 Oops: 0003 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8433 Comm: syz-executor067 Tainted: G W 5.13.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga16fb_fillrect+0x993/0x18d0 drivers/video/fbdev/vga16fb.c:923 Code: 6c fd 48 63 44 24 10 45 31 f6 48 89 04 24 e8 44 a6 6c fd 31 ff 89 de 31 ed e8 79 ad 6c fd 85 db 4d 89 ec 74 22 e8 2d a6 6c fd <45> 88 34 24 83 c5 01 89 df 49 83 c4 01 89 ee e8 49 ae 6c fd 39 eb RSP: 0018:ffffc90000eff848 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000001b RCX: 0000000000000000 RDX: ffff88802d949c40 RSI: ffffffff8408e403 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8408dd8d R10: ffffffff8408e3f7 R11: 0000000000000000 R12: ffff888001000050 R13: ffff888001000050 R14: 0000000000000000 R15: 000000000ffeb7ff FS: 0000000001aa2300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888001000050 CR3: 00000000346fb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bit_clear_margins+0x3f6/0x4b0 drivers/video/fbdev/core/bitblit.c:224 fbcon_clear_margins+0x1f1/0x280 drivers/video/fbdev/core/fbcon.c:1315 fbcon_switch+0xa8c/0x1620 drivers/video/fbdev/core/fbcon.c:2146 redraw_screen+0x2b9/0x740 drivers/tty/vt/vt.c:1021 fbcon_modechanged+0x593/0x6d0 drivers/video/fbdev/core/fbcon.c:2651 fbcon_update_vcs+0x3a/0x50 drivers/video/fbdev/core/fbcon.c:2696 do_fb_ioctl+0x62e/0x690 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl fs/ioctl.c:1055 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43efd9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc362df848 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043efd9 RDX: 0000000020000200 RSI: 0000000000004601 RDI: 0000000000000003 RBP: 0000000000402fc0 R08: 0000000000000000 R09: 0000000000400488 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000403050 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488 Modules linked in: CR2: ffff888001000050 ---[ end trace 39dce64bc5621bd3 ]--- RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga16fb_fillrect+0x993/0x18d0 drivers/video/fbdev/vga16fb.c:923 Code: 6c fd 48 63 44 24 10 45 31 f6 48 89 04 24 e8 44 a6 6c fd 31 ff 89 de 31 ed e8 79 ad 6c fd 85 db 4d 89 ec 74 22 e8 2d a6 6c fd <45> 88 34 24 83 c5 01 89 df 49 83 c4 01 89 ee e8 49 ae 6c fd 39 eb RSP: 0018:ffffc90000eff848 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000001b RCX: 0000000000000000 RDX: ffff88802d949c40 RSI: ffffffff8408e403 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8408dd8d R10: ffffffff8408e3f7 R11: 0000000000000000 R12: ffff888001000050 R13: ffff888001000050 R14: 0000000000000000 R15: 000000000ffeb7ff FS: 0000000001aa2300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888001000050 CR3: 00000000346fb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

7 25

← Newer
1
...
66
67
68
69
70
71
72
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021