- 15 Oct, 2021 3 commits
-
-
Matthew Brost authored
Move guc_id allocation under submission state sub-struct as a future patch will reuse the spin lock as a global submission state lock. Moving this into sub-struct makes ownership of fields / lock clear. v2: (Docs) - Add comment for submission_state sub-structure v3: (John Harrison) - Fixup a few comments v4: (John Harrison) - Fix typo Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Andi Shyti authored
The following interfaces: i915_wedged i915_forcewake_user are dependent on gt values. Put them inside gt/ and drop the "i915_" prefix name. This would be the new structure: dri/0/gt | +-- forcewake_user | \-- reset For backwards compatibility with existing igt (and the slight semantic difference between operating on the i915 abi entry points and the deep gt info): dri/0 | +-- i915_wedged | \-- i915_forcewake_user remain at the top level. Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Hugh Dickins authored
5.15-rc1 crashes with blank screen when booting up on two ThinkPads using i915. Bisections converge convincingly, but arrive at different and surprising "culprits", none of them the actual culprit. netconsole (with init_netconsole() hacked to call i915_init() when logging has started, instead of by module_init()) tells the story: kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! with RSI: ffffffff814d408b pointing to sw_fence_dummy_notify(). I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that function needs to be 4-byte aligned. v2: (Jani Nikula) - Change BUG_ON to WARN_ON v3: (Jani / Tvrtko) - Short circuit __i915_sw_fence_init on WARN_ON v4: (Lucas) - Break WARN_ON changes out in a different patch Fixes: 62eaf0ae ("drm/i915/guc: Support request cancellation") Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
- 12 Oct, 2021 3 commits
-
-
Matt Roper authored
The I915_TILING_* definitions in the uapi header are intended solely for tiling modes that are visible to the old de-tiling fence ioctls. Since modern hardware does not support de-tiling fences, we should not add new definitions for new tiling types going forward. However we do want the client blit selftest to eventually cover other new tiling modes (such as Tile4), so switch it to using its own enum of tiling modes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001005816.73330-1-matthew.d.roper@intel.com
-
Lucas De Marchi authored
Let's include what we use instead of relying on other indirect includes. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211007233212.3896460-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
We are currently using tsc_khz as a fallback so add the right include. For other architectures we may need to add a different fallback, but this is not being used by dgfx so we may as well just paper it over. Signed-off-by:
-
- 07 Oct, 2021 1 commit
-
-
Lucas De Marchi authored
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't provide much value just encapsulating it in a boolean context. So I also added the support for handling undefined macros as the IS_ENABLED() counterpart. However the feedback received from Masahiro Yamada was that it is too ugly, not providing much value. And just wrapping in a boolean context is too dumb - we could simply open code it. As detailed in commit babaab2f ("drm/i915: Encapsulate kconfig constant values inside boolean predicates"), the IS_ACTIVE macro was added to workaround a compilation warning. However after checking again our current uses of IS_ACTIVE it turned out there is only 1 case in which it triggers a warning in clang (due -Wconstant-logical-operand) and 2 in smatch. All the others can simply use the shorter version, without wrapping it in any macro. So here I'm dialing all the way back to simply removing the macro. That single case hit by clang can be changed to make the constant come first, so it doesn't think it's mask: - if (context && CONFIG_DRM_I915_FENCE_TIMEOUT) + if (CONFIG_DRM_I915_FENCE_TIMEOUT && context) As talked with Dan Carpenter, that logic will be added in smatch as well, so it will also stop warning about it. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Masahiro Yamada <masahiroy@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211005171728.3147094-1-lucas.demarchi@intel.com
-
- 06 Oct, 2021 1 commit
-
-
Tvrtko Ursulin authored
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) when rendering is done on Intel dgfx and scanout/composition on Intel igfx. Before this patch the driver was not quite ready for that setup, mainly because it was able to emit a semaphore wait between the two GPUs, which results in deadlocks because semaphore target location in HWSP is neither shared between the two, nor mapped in both GGTT spaces. To fix it the patch adds an additional check to a couple of relevant code paths in order to prevent using semaphores for inter-engine synchronisation when relevant objects are not in the same GGTT space. v2: * Avoid adding rq->i915. (Chris) v3: * Use GGTT which describes the limit more precisely. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113135.768295-1-tvrtko.ursulin@linux.intel.com
-
- 05 Oct, 2021 1 commit
-
-
Matthew Brost authored
Set number of engines before attempting to create contexts so the function free_engines can clean up properly. Also check return of alloc_engines for NULL. v2: (Tvrtko) - Send as stand alone patch (John Harrison) - Check for alloc_engines returning NULL v3: (Checkpatch / Tvrtko) - Remove braces around single line if statement Cc: Jason Ekstrand <jason@jlekstrand.net> Fixes: d4433c76 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Reviewed-by:
-
- 04 Oct, 2021 18 commits
-
-
Nathan Chancellor authored
i915 enables a wider set of warnings with '-Wall -Wextra' then disables several with cc-disable-warning. If an unknown flag gets added to KBUILD_CFLAGS when building with clang, all subsequent calls to cc-{disable-warning,option} will fail, meaning that all of these warnings do not get disabled [1]. A separate series will address the root cause of the issue by not adding these flags when building with clang [2]; however, the symptom of these extra warnings appearing can be addressed separately by just removing the calls to cc-disable-warning, which makes the build ever so slightly faster because the compiler does not need to be called as much before building. The following warnings are supported by GCC 4.9 and clang 10.0.1, which are the minimum supported versions of these compilers so the call to cc-disable-warning is not necessary. Masahiro cleaned this up for the reset of the kernel in commit 4c8dd95a ("kbuild: add some extra warning flags unconditionally"). * -Wmissing-field-initializers * -Wsign-compare * -Wtype-limits * -Wunused-parameter -Wunused-but-set-variable was implemented in clang 13.0.0 and -Wframe-address was implemented in clang 12.0.0 so the cc-disable-warning calls are kept for these two warnings. Lastly, -Winitializer-overrides is clang's version of -Woverride-init, which is disabled for the specific files that are problematic. clang added a compatibility alias in clang 8.0.0 so -Winitializer-overrides can be removed. [1]: https://lore.kernel.org/r/202108210311.CBtcgoUL-lkp@intel.com/ [2]: https://lore.kernel.org/r/20210824022640.2170859-1-nathan@kernel.org/Reviewed-by:Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Note that discrete cards can support PXP as well, but we haven't tested on those yet so keeping it disabled for now. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Now that all the pieces are in place we can add a description of how the feature works. Also modify the comments in struct intel_pxp into kerneldoc. v2: improve doc (Rodrigo) Signed-off-by:
-
Daniele Ceraolo Spurio authored
2 debugfs files, one to query the current status of the pxp session and one to trigger an invalidation for testing. v2: rename debugfs, fix date (Alan) v12: rebased to latest drm-tip (rename of files/structs from debugfs_gt to intel_debugfs_gt caused compiler errors). Signed-off-by:Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
-
Anshuman Gupta authored
When protected sufaces has flipped and pxp session is disabled, display black pixels by using plane color CTM correction. v2: - Display black pixels in async flip too. v3: - Removed the black pixels logic for async flip. [Ville] - Used plane state to force black pixels. [Ville] v4 (Daniele): update pxp_is_borked check. v5: rebase on top of v9 plane decryption moving the decrypt check (Juston) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gaurav Kumar <kumar.gaurav@intel.com> Cc: Shankar Uma <uma.shankar@intel.com> Signed-off-by:Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Juston Li <juston.li@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Add support to enable/disable PLANE_SURF Decryption Request bit. It requires only to enable plane decryption support when following condition met. 1. PXP session is enabled. 2. Buffer object is protected. v2: - Used gen fb obj user_flags instead gem_object_metadata. [Krishna] v3: - intel_pxp_gem_object_status() API changes. v4: use intel_pxp_is_active (Daniele) v5: rebase and use the new protected object status checker (Daniele) v6: used plane state for plane_decryption to handle async flip as suggested by Ville. v7: check pxp session while plane decrypt state computation. [Ville] removed pointless code. [Ville] v8 (Daniele): update PXP check v9: move decrypt check after icl_check_nv12_planes() when overlays have fb set (Juston) v10 (Daniele): update PXP check again to match rework in earlier patches and don't consider protection valid if the object has not been used in an execbuf beforehand. Cc: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Huang Sean Z <sean.z.huang@intel.com> Cc: Gaurav Kumar <kumar.gaurav@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Huang, Sean Z authored
During the power event S3+ sleep/resume, hardware will lose all the encryption keys for every hardware session, even though the session state might still be marked as alive after resume. Therefore, we should consider the session as dead on suspend and invalidate all the objects. The session will be automatically restarted on the first protected submission on resume. v2: runtime suspend also invalidates the keys v3: fix return codes, simplify rpm ops (Chris), use the new worker func v4: invalidate the objects on suspend, don't re-create the arb sesson on resume (delayed to first submission). v5: move irq changes back to irq patch (Rodrigo) v6: drop invalidation in runtime suspend (Rodrigo) Signed-off-by:
Huang, Sean Z <sean.z.huang@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Now that we can handle destruction and re-creation of the arb session, we can postpone the start of the session to the first submission that requires it, to avoid keeping it running with no user. v10: increase timeout when waiting in intel_pxp_start as firmware session startup is slower right after boot. v13: increase the same timeout by 50 milisec because previous timeout was not enough to cover two lower level 100 milisec timeouts in the session termination + creation steps. Signed-off-by: -
Daniele Ceraolo Spurio authored
This api allow user mode to create protected buffers and to mark contexts as making use of such objects. Only when using contexts marked in such a way is the execution guaranteed to work as expected. Contexts can only be marked as using protected content at creation time (i.e. the parameter is immutable) and they must be both bannable and not recoverable. Given that the protected session gets invalidated on suspend, contexts created this way hold a runtime pm wakeref until they're either destroyed or invalidated. All protected objects and contexts will be considered invalid when the PXP session is destroyed and all new submissions using them will be rejected. All intel contexts within the invalidated gem contexts will be marked banned. Userspace can detect that an invalidation has occurred via the RESET_STATS ioctl, where we report it the same way as a ban due to a hang. v5: squash patches, rebase on proto_ctx, update kerneldoc v6: rebase on obj create_ext changes v7: Use session counter to check if an object it valid, hold wakeref in context, don't add a new flag to RESET_STATS (Daniel) v8: don't increase guilty count for contexts banned during pxp invalidation (Rodrigo) v9: better comments, avoid wakeref put race between pxp_inval and context_close, add usage examples (Rodrigo) v10: modify internal set/get-protected-context functions to not return -ENODEV when setting PXP param to false or getting param when running on pxp-unsupported hw or getting param when i915 was built with CONFIG_PXP off Signed-off-by:Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
-
Huang, Sean Z authored
The HW will generate a teardown interrupt when session termination is required, which requires i915 to submit a terminating batch. Once the HW is done with the termination it will generate another interrupt, at which point it is safe to re-create the session. Since the termination and re-creation flow is something we want to trigger from the driver as well, use a common work function that can be called both from the irq handler and from the driver set-up flows, which has the addded benefit of allowing us to skip any extra locks because the work itself serializes the operations. v2: use struct completion instead of bool (Chris) v3: drop locks, clean up functions and improve comments (Chris), move to common work function. v4: improve comments, simplify wait logic (Rodrigo) v5: unconditionally set interrupts, rename state_attacked var (Rodrigo) v10: remove inclusion of intel_gt_types.h from intel_pxp.h (Jani) Signed-off-by: -
Huang, Sean Z authored
Teardown is triggered when the display topology changes and no long meets the secure playback requirement, and hardware trashes all the encryption keys for display. Additionally, we want to emit a teardown operation to make sure we're clean on boot and resume v2: emit in the ring, use high prio request (Chris) v3: better defines, stalling flush, cleaned up and renamed submission funcs (Chris) v12: fix uninitialized variable bug Signed-off-by: -
Huang, Sean Z authored
Create the arbitrary session, with the fixed session id 0xf, after system boot, for the case that application allocates the protected buffer without establishing any protection session. Because the hardware requires at least one alive session for protected buffer creation. This arbitrary session will need to be re-created after teardown or power event because hardware encryption key won't be valid after such cases. The session ID is exposed as part of the uapi so it can be used as part of userspace commands. v2: use gt->uncore->rpm (Chris) v3: s/arb_is_in_play/arb_is_valid (Chris), move set-up to the new init_hw function v4: move interface defs to separate header, set arb_is valid to false on fini (Rodrigo) v5: handle async component binding Signed-off-by: -
Daniele Ceraolo Spurio authored
The setting is required by hardware to allow us doing further protection operation such as sending commands to GPU or TEE. The register needs to be re-programmed on resume, so for simplicitly we bundle the programming with the component binding, which is automatically called on resume. Further HW set-up operations will be added in the same location in follow-up patches, so get ready for them by using a couple of init/fini_hw wrappers instead of calling the KCR funcs directly. v3: move programming to component binding function, rework commit msg Signed-off-by:
-
Huang, Sean Z authored
Implement the funcs to create the TEE channel, so kernel can send the TEE commands directly to TEE for creating the arbitrary (default) session. v2: fix locking, don't pollute dev_priv (Chris) v3: wait for mei PXP component to be bound. v4: drop the wait, as the component might be bound after i915 load completes. We'll instead check when sending a tee message. v5: fix an issue with mei_pxp module removal v6: don't use fetch_and_zero in fini (Rodrigo) Signed-off-by:
-
Daniele Ceraolo Spurio authored
The context is required to send the session termination commands to the VCS, which will be implemented in a follow-up patch. We can also use the presence of the context as a check of pxp initialization completion. v2: use perma-pinned context (Chris) v3: rename pinned_context functions (Chris) v4: split export of pinned_context functions to a separate patch (Rodrigo) v10: remove inclusion of intel_gt_types.h from intel_pxp.h (Jani) v13: fixed for loop pointer dereference (Vinay) Signed-off-by:
-
Daniele Ceraolo Spurio authored
Ahead of the PXP implementation, define the relevant define flag and kconfig option. v2: flip kconfig default to N. Some machines have IFWIs that do not support PXP, so we need it to be an opt-in until we add support to query the caps from the mei device. v10: change comments from "Gen12+" to "Gen12 and newer" Signed-off-by:
-
Vitaly Lubart authored
Export PAVP client to work with i915 driver, for binding it uses kernel component framework. v2:drop debug prints, refactor match code to match mei_hdcp (Tomas) Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
This will be used for communication between the i915 driver and the mei one. Defining it in a stand-alone patch to avoid circualr dependedencies between the patches modifying the 2 drivers. Split out from an original patch from Huang, Sean Z v2: rename the component struct (Rodrigo) Signed-off-by:
-
- 01 Oct, 2021 6 commits
-
-
Michal Wajdeczko authored
If we timeout waiting for a CT reply we print very simple error message. Improve that and by moving error reporting to the caller we can use CT_ERROR instead of DRM_ERROR and report just fence as error code will be reported later anyway. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Michal Wajdeczko authored
Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by:
-
Michal Wajdeczko authored
Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by:
-
Michal Wajdeczko authored
In commit b839a869 ("drm/i915/guc: Add support for data reporting in GuC responses") we missed the hypothetical case that GuC might return positive non-zero value as success data. While that would be lucky treated as error case, and at the end will result in reporting valid -EIO, in the meantime this value will be passed to ERR_PTR that could be misleading. v2: rebased Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Michal Wajdeczko authored
We assumed that for all modern GENs the PTEs and register space are split in the GTTMMADR BAR, but while it is true, we should rather use fixed offset as it is defined in the specification. Bspec: 4409, 4457, 4604, 11181, 9027, 13246, 13321, 44980 Signed-off-by:
-
Thomas Hellström authored
We may end up in i915_ttm_bo_destroy() in an error path before the object is fully initialized. In that case it's not correct to call __i915_gem_free_object(), because that function a) Assumes the gem object refcount is 0, which it isn't. b) frees the placements which are owned by the caller until the init_object() region ops returns successfully. Fix this by providing a lightweight cleanup function __i915_gem_object_fini() which is also called by __i915_gem_free_object(). While doing this, also make sure we call dma_resv_fini() as part of ordinary object destruction and not from the RCU callback that frees the object. This will help track down bugs where the object is incorrectly locked from an RCU lookup. Finally, make sure the object isn't put on the region list until it's either locked or fully initialized in order to block list processing of partially initialized objects. v2: - The TTM object backend memory was freed before the gem pages were put. Separate this functionality into __i915_gem_object_pages_fini() and call it from the TTM delete_mem_notify() callback. v3: - Include i915_gem_object_free_mmaps() in __i915_gem_object_pages_fini() to make sure we don't inadvertedly introduce a race. Fixes: 48b09612 ("drm/i915: Move __i915_gem_free_object to ttm_bo_destroy") Signed-off-by:
-
- 30 Sep, 2021 1 commit
-
-
Cai Huoqing authored
Replace direction definition PCI_DMA_BIDIRECTIONAL with DMA_BIDIRECTIONAL, because it helps to enhance readability and avoid possible inconsistency. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
- 29 Sep, 2021 1 commit
-
-
Maarten Lankhorst authored
We forgot to call intel_runtime_pm_put on error, fix it! Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: cf41a8f1 ("drm/i915: Finally remove obj->mm.lock.") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v5.13+ Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210830121006.2978297-9-maarten.lankhorst@linux.intel.com
-
- 27 Sep, 2021 1 commit
-
-
Matthew Auld authored
Seems to fix some object-debug splat which appeared while debugging something unrelated. v2: s/guc_blocked/guc_state.blocked/ Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Tested-by:
-
- 25 Sep, 2021 1 commit
-
-
Janusz Krzysztofik authored
We currently do an explicit flush of the buffer pools within the call path of drm_driver.release(); this removes all buffers, regardless of their age, freeing the buffers' associated resources (objects, address space areas). However there is other code that runs within the drm_driver.release() call chain that expects objects and their associated address space areas have already been flushed. Since buffer pools auto-flush old buffers once per second in a worker thread, there's a small window where if we remove the driver while there are still objects in buffers with an age of less than one second, the assumptions of the other release code may be violated. By moving the flush to driver remove (which executes earlier via the pci_driver.remove() flow) we're ensuring that all buffers are flushed and their associated objects freed before some other code in pci_driver.remove() flushes those objects so they are released before _any_ code in drm_driver.release() that check completness of those flushes executes. v2: Reword commit description as suggested by Matt. Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 24 Sep, 2021 3 commits
-
-
Tejas Upadhyay authored
In commit 4e5c8a99 ("drm/i915: Drop i915_request.lock requirement for intel_rps_boost()"), we decoupled the rps worker from the pm so that we could avoid the synchronization penalty which makes the assertion liable to run too early. Which makes warning invalid hence removed. Fixes: 4e5c8a99 ("drm/i915: Drop i915_request.lock requirement for intel_rps_boost()") Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
-
Matthew Auld authored
In commit: commit 1e6decf3 Author: Hugh Dickins <hughd@google.com> Date: Thu Sep 2 14:54:43 2021 -0700 shmem: shmem_writepage() split unlikely i915 THP it looks THP + shmem_writeback was an unexpected combination, and ends up hitting some BUG_ON, but it also looks like that is now fixed. While the IGTs did eventually hit this(although not during pre-merge it seems), it's likely worthwhile adding some explicit coverage for this scenario in the shrink_thp selftest. References: https://gitlab.freedesktop.org/drm/intel/-/issues/4166Signed-off-by:
-
Matthew Auld authored
Currently we blow up in trace_dma_fence_init, when calling into get_driver_name or get_timeline_name, since both the engine and context might be NULL(or contain some garbage address) in the case of newly allocated slab objects via the request ctor. Note that we also use SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately freed, but delay freeing the underlying page by an RCU grace period. With this scheme requests can be re-allocated, at the same time as they are also being read by some lockless RCU lookup mechanism. In the ctor case, which is only called for new slab objects(i.e allocate new page and call the ctor for each object) it's safe to reset the context/engine prior to calling into dma_fence_init, since we can be certain that no one is doing an RCU lookup which might depend on peeking at the engine/context, like in active_engine(), since the object can't yet be externally visible. In the recycled case(which might also be externally visible) the request refcount always transitions from 0->1 after we set the context/engine etc, which should ensure it's valid to dereference the engine for example, when doing an RCU list-walk, so long as we can also increment the refcount first. If the refcount is already zero, then the request is considered complete/released. If it's non-zero, then the request might be in the process of being re-allocated, or potentially still in flight, however after successfully incrementing the refcount, it's possible to carefully inspect the request state, to determine if the request is still what we were looking for. Note that all externally visible requests returned to the cache must have zero refcount. One possible fix then is to move dma_fence_init out from the request ctor. Originally this was how it was done, but it was moved in: commit 855e39e6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Feb 3 09:41:48 2020 +0000 drm/i915: Initialise basic fence before acquiring seqno where it looks like intel_timeline_get_seqno() relied on some of the rq->fence state, but that is no longer the case since: commit 12ca695d Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Mar 23 16:49:50 2021 +0100 drm/i915: Do not share hwsp across contexts any more, v8. intel_timeline_get_seqno() could also be cleaned up slightly by dropping the request argument. Moving dma_fence_init back out of the ctor, should ensure we have enough of the request initialised in case of trace_dma_fence_init. Functionally this should be the same, and is effectively what we were already open coding before, except now we also assign the fence->lock and fence->ops, but since these are invariant for recycled requests(which might be externally visible), and will therefore already hold the same value, it shouldn't matter. An alternative fix, since we don't yet have a fully initialised request when in the ctor, is just setting the context/engine as NULL, but this does require adding some extra handling in get_driver_name etc. v2(Daniel): - Try to make the commit message less confusing Fixes: 855e39e6 ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by:
-
