- 15 1月, 2019 15 次提交
-
-
由 Chris Wilson 提交于
Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-15-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Track the temporary wakerefs used within the selftests so that leaks are clear. v2: Add a couple of coarse annotations for mock selftests as we now loudly warn about the errors. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-14-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of the temporary rpm wakeref used for panel backlight access, so that we can cancel it immediately upon release and so more clearly identify leaks. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-13-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of the temporary rpm wakeref inside hotplug detection, so that we can cancel it immediately upon release and so clearly identify leaks. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-12-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of the rpm wakeref used for framebuffer access so that we can cancel upon release and so more clearly identify leaks. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-11-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of the temporary rpm wakerefs used for user access to the device, so that we can cancel them upon release and clearly identify any leaks. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-10-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of our acquired wakeref for interacting with the guc, so that we can cancel it upon release and so clearly identify leaks. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-9-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Track the wakeref used for temporary access to the device, and discard it upon release so that leaks can be identified. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-8-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep track of our wakeref used to keep the device awake so we can catch any leak. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-7-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
As debugfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-6-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
As sysfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-5-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Keep hold of the local wakeref used in error handling, to cancel the tracking upon release so that leaks can be identified. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-4-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Record the wakeref used for keeping the device awake as the GPU is executing requests and be sure to cancel the tracking upon parking. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-3-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Everytime we take a wakeref, record the stack trace of where it was taken; clearing the set if we ever drop back to no owners. For debugging a rpm leak, we can look at all the current wakerefs and check if they have a matching rpm_put. v2: Use skip=0 for unwinding the stack as it appears our noinline function doesn't appear on the stack (nor does save_stack_trace itself!) v3: Allow rpm->debug_count to disappear between inspections and so avoid calling krealloc(0) as that may return a ZERO_PTR not NULL! (Mika) v4: Show who last acquire/released the runtime pm Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Tested-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-1-chris@chris-wilson.co.uk
-
- 11 1月, 2019 1 次提交
-
-
由 Rodrigo Vivi 提交于
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 10 1月, 2019 7 次提交
-
-
由 Chris Wilson 提交于
The wait-for-idle used from within the shrinker_lock_uninterruptible depends on the struct_mutex locking state being known and declared to i915_request_wait(). As it is conceivable that we reach the vmap notifier from underneath struct_mutex (and so keep on relying on the mutex_trylock_recursive), we should not blindly call i915_request_wait. In the process we can remove the dubious polling to acquire struct_mutex, and simply act, or not, on a successful trylock. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109164204.23935-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
If the current process is being killed (it was interrupted with SIGKILL or equivalent), it will not make any progress in page allocation and we can abort performing the shrinking on its behalf. So we can use mutex_lock_killable() instead (although this path should only be reachable from kswapd currently). Tvrtko pointed out that it should also be reachable from debugfs, which he would prefer retain its interruptiblity. As a compromise, killable is a step in the right direction! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109164204.23935-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
If we find an incompletely setup vma inside the request/engine at the time of a hang, it may not have vma->pages initialised, so skip capturing the object before we iterate over NULL. Spotted by Matthew in preparation for using unpinned vma to track engine state. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110111522.11023-1-chris@chris-wilson.co.uk
-
由 Daniele Ceraolo Spurio 提交于
The only gen8+ platform that has the feature is BDW, but we don't define the feature flag on any BDW platform and we only have partial support in the gen8 path (irq enabling code, but no handler). The only thing we could do in the irq handler is report the error to userspace, but no one asked/cared about that since BDW was released so it is relatively safe to assume that even if we added the message no one would look at it. Just drop the dead code from the driver instead. Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190109213147.16851-1-daniele.ceraolospurio@intel.com
-
由 Daniele Ceraolo Spurio 提交于
commit 4a15c75c ("drm/i915: Introduce per-engine workarounds") refactored the workaround code to have functions per-engine, but didn't call any of them from logical_xcs_ring_init. Since we do have a non-RCS workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call intel_engine_init_workarounds for non-RCS engines. Note that whitelist is still RCS-only. v2: move the call to logical_ring_init (Chris) Fixes: 4a15c75c ("drm/i915: Introduce per-engine workarounds") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-2-daniele.ceraolospurio@intel.com
-
由 Daniele Ceraolo Spurio 提交于
By using the wa lists inside the live driver structures, we won't catch issues where those are incorrectly setup or corrupted. To cover this gap, update the workaround framework to allow saving the wa lists to independent structures and use them in the selftests. Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-1-daniele.ceraolospurio@intel.com [tursulin: Fixup checkpatch whitespace complaint in memset.]
-
由 Chris Wilson 提交于
In the continual quest to reduce the amount of global work required when submitting requests, replace i915_retire_requests() after allocation failure to retiring just our ring. v2: Don't forget the list iteration included an early break, so we would never throttle on the last request in the ring/timeline. v3: Use the common ring_retire_requests() References: 11abf0c5 ("drm/i915: Limit the backpressure for i915_request allocation") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109215932.26454-1-chris@chris-wilson.co.uk
-
- 09 1月, 2019 3 次提交
-
-
由 Hans de Goede 提交于
Add support for PMIC MIPI sequences using the new intel_soc_pmic_exec_mipi_pmic_seq_element function. This fixes the DSI LCD panel not lighting up when not initialized by the GOP (because an external monitor was connected) on GPD win and GPD pocket devices. Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be driven high, which is done through a PMIC MIPI sequence. Before this commit if the sequence was not executed by the GOP the pin would stay low causing the LCD panel to not work. Having the MIPI sequences properly control this GPIO should also help save some power when the panel is off. Changes in v2, v3: -Only changes to other patches in this patch-set Changes in v4: -Move decoding of the raw 15 bytes PMIC MIPI sequence element into i2c-address, register-address, value and mask into the mipi_exec_pmic() function instead of passing the raw data to intel_soc_pmic_exec_mipi_pmic_seq_element() Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-5-hdegoede@redhat.com
-
由 Jani Nikula 提交于
Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
-
由 Chris Wilson 提交于
If we haven't shipped and enabled firmware for a particular platform, there is nothing the user can do about it. Don't scare the user with an unactionable, unidentifiable warning! <6> [310.769452] i915 0000:00:02.0: GuC: No firmware known for this platform! <4> [310.769458] [drm] HuC: No firmware known for this platform! Unify both GuC/HuC messages to include the device for which we lack the firmware, and provide the platform name as an aide-memoire. v2: Move and refine the message to common site of intel_uc_fw_fetch. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108150246.1471-1-chris@chris-wilson.co.uk
-
- 08 1月, 2019 3 次提交
-
-
由 Jani Nikula 提交于
Minimal change to nuke the static buf. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107145149.10069-1-jani.nikula@intel.com
-
由 Chris Wilson 提交于
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency for non-i915 clients at an increased risk of being unable to obtain a page from direct-reclaim without hitting the oom-notifier. The proviso being that we still keep trying to hard obtain the lock for kswapd so that we can reap under heavy memory pressure. v2: Taint all mutexes taken within the shrinker with the struct_mutex subclass as an early warning system, and drop I915_SHRINK_ACTIVE from vmap to reduce the number of dangerous paths. We also have to drop I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim that ACTIVE is only used from outside context, which fits in with a longer strategy of avoiding stalls due to scanning active during shrinking. The danger in using the subclass struct_mutex is that we declare ourselves more knowledgable than lockdep and deprive ourselves of automatic coverage. Instead, we require ourselves to mark up any mutex taken inside the shrinker in order to detect lock-inversion, and if we miss any we are doomed to a deadlock at the worst possible moment. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107115509.12523-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Being a mock device, we suffer no DMA restrictions, so set the coherent mask to 64b. v2: Fix up mock_huge_selftests Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109243Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107181856.23789-1-chris@chris-wilson.co.uk
-
- 07 1月, 2019 3 次提交
-
-
由 Chris Wilson 提交于
Include the total size of closed vma when reporting the per_ctx_stats of debugfs/i915_gem_objects. Whilst adjusting the context tracking, note that we can simply use our list of contexts in i915->contexts rather than circumlocute via dev->filelist and the per-file context idr, with the result that we can show objects allocated to different vm (i.e. contexts within a file). We change the output to show every context of each client, with its own unique set of objects (for full-ppgtt machines, i.e. gen7+, for older hardware all objects are in the global gtt and so can not be associated with a single context). That should result in no loss of information, and for gen7+, no duplication of active objects. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107115509.12523-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Haswell also requires the RING_IMR flush for its unique vebox setup to avoid losing interrupts, as per 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR"): On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. References: 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105115647.4970-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
CC [M] drivers/gpu/drm/i915/intel_device_info.o drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or member 'dev_priv' not described in 'intel_device_info_runtime_init' drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function parameter 'info' description in 'intel_device_info_runtime_init' Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105014652.3472-1-chris@chris-wilson.co.uk
-
- 05 1月, 2019 3 次提交
-
-
由 Chris Wilson 提交于
Our attempt to account for bit17 swizzling of pread/pwrite onto tiled objects was flawed due to the simple fact that we do not always know the swizzling for a particular page (due to the swizzling varying based on location in certain unbalanced configurations). Furthermore, the pread/pwrite paths are now unbalanced in that we are required to use the GTT as in some cases we do not have direct CPU access to the backing physical pages (thus some paths trying to account for the swizzle, but others neglecting, chaos ensues). There are no known users who do use pread/pwrite into a tiled object (you need to manually detile anyway, so why now just use mmap and avoid the copy?) and no user bug reports to indicate that it is being used in the wild. As no one is hitting the buggy path, we can just remove the buggy code. v2: Just use the fault allowing kmap() + normal copy_(to|from)_user v3: Avoid int overflow in computing 'length' from 'remain' (Tvrtko) References: fe115628 ("drm/i915: Implement pwrite without struct-mutex") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190105120758.9237-1-chris@chris-wilson.co.uk
-
由 Linus Torvalds 提交于
Originally, the rule used to be that you'd have to do access_ok() separately, and then user_access_begin() before actually doing the direct (optimized) user access. But experience has shown that people then decide not to do access_ok() at all, and instead rely on it being implied by other operations or similar. Which makes it very hard to verify that the access has actually been range-checked. If you use the unsafe direct user accesses, hardware features (either SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged Access Never - on ARM) do force you to use user_access_begin(). But nothing really forces the range check. By putting the range check into user_access_begin(), we actually force people to do the right thing (tm), and the range check vill be visible near the actual accesses. We have way too long a history of people trying to avoid them. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
When commit fddcd00a ("drm/i915: Force the slow path after a user-write error") unified the error handling for various user access problems, it didn't do the user_access_end() that is needed for the unsafe_put_user() case. It's not a huge deal: a missed user_access_end() will only mean that SMAP protection isn't active afterwards, and for the error case we'll be returning to user mode soon enough anyway. But it's wrong, and adding the proper user_access_end() is trivial enough (and doing it for the other error cases where it isn't needed doesn't hurt). I noticed it while doing the same prep-work for changing user_access_begin() that precipitated the access_ok() changes in commit 96d4f267 ("Remove 'type' argument from access_ok() function"). Fixes: fddcd00a ("drm/i915: Force the slow path after a user-write error") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@kernel.org # v4.20 Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 1月, 2019 2 次提交
-
-
由 Chris Wilson 提交于
If we declare the driver wedged during early initialisation, we leave the driver in an undefined state (with respect to GEM execution). As this leads to unexpected behaviour if we allow the user to unwedge the device (through debugfs, and performed by igt at test start), do not. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103213340.1669-1-chris@chris-wilson.co.uk
-
由 Linus Torvalds 提交于
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 1月, 2019 3 次提交
-
-
由 Chris Wilson 提交于
When we first introduced the reset to sanitize the GPU on taking over from the BIOS and before returning control to third parties (the BIOS!), we restricted it to only systems utilizing HW contexts as we were uncertain of how stable our reset mechanism truly was. We now have reasonable coverage across all machines that expose a GPU reset method, and so we should be safe to sanitize the GPU state everywhere. v2: We _have_ to skip the reset if it would clobber the display. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103112104.19561-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
As the question of 32b/64b kernels became relevant in the light of certain bugs, include that information in the error state. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103101245.15100-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190102163524.19353-1-chris@chris-wilson.co.uk
-