* [PATCH 4.4 1/1] drm/i915: Flush TLBs before releasing backing store
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
@ 2022-01-27 18:08 ` Greg Kroah-Hartman
2022-01-27 19:43 ` [PATCH 4.4 0/1] 4.4.301-rc1 review Pavel Machek
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Greg Kroah-Hartman @ 2022-01-27 18:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tvrtko Ursulin,
Sushma Venkatesh Reddy, Daniel Vetter, Dave Airlie,
Jon Bloomfield, Joonas Lahtinen, Jani Nikula, Linus Torvalds
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
commit 7938d61591d33394a21bdd7797a245b65428f44c upstream.
We need to flush TLBs before releasing backing store otherwise userspace
is able to encounter stale entries if a) it is not declaring access to
certain buffers and b) it races with the backing store release from a
such undeclared execution already executing on the GPU in parallel.
The approach taken is to mark any buffer objects which were ever bound
to the GPU and to trigger a serialized TLB flush when their backing
store is released.
Alternatively the flushing could be done on VMA unbind, at which point
we would be able to ascertain whether there is potential a parallel GPU
execution (which could race), but essentially it boils down to paying
the cost of TLB flushes potentially needlessly at VMA unbind time (when
the backing store is not known to be going away so not needed for
safety), versus potentially needlessly at backing store relase time
(since we at that point cannot tell whether there is anything executing
on the GPU which uses that object).
Thereforce simplicity of implementation has been chosen for now with
scope to benchmark and refine later as required.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/i915_gem.c | 89 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
4 files changed, 103 insertions(+)
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1719,6 +1719,8 @@ struct drm_i915_private {
struct intel_uncore uncore;
+ struct mutex tlb_invalidate_lock;
+
struct i915_virtual_gpu vgpu;
struct intel_guc guc;
@@ -2066,6 +2068,9 @@ struct drm_i915_gem_object {
*/
unsigned int active:I915_NUM_RINGS;
+ unsigned long flags;
+#define I915_BO_WAS_BOUND_BIT 0
+
/**
* This is set if the object has been written to since last bound
* to the GTT
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2212,6 +2212,85 @@ i915_gem_object_put_pages_gtt(struct drm
kfree(obj->pages);
}
+#define _wait_for_us(COND, US, W) ({ \
+ unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1; \
+ int ret__; \
+ for (;;) { \
+ bool expired__ = time_after(jiffies, timeout__); \
+ if (COND) { \
+ ret__ = 0; \
+ break; \
+ } \
+ if (expired__) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ usleep_range((W), (W)*2); \
+ } \
+ ret__; \
+})
+
+static int
+__intel_wait_for_register_fw(struct drm_i915_private *dev_priv,
+ u32 reg,
+ const u32 mask,
+ const u32 value,
+ const unsigned int timeout_us,
+ const unsigned int timeout_ms)
+{
+#define done ((I915_READ_FW(reg) & mask) == value)
+ int ret = _wait_for_us(done, timeout_us, 2);
+ if (ret)
+ ret = wait_for(done, timeout_ms);
+ return ret;
+#undef done
+}
+
+static void invalidate_tlbs(struct drm_i915_private *dev_priv)
+{
+ static const u32 gen8_regs[] = {
+ [RCS] = GEN8_RTCR,
+ [VCS] = GEN8_M1TCR,
+ [VCS2] = GEN8_M2TCR,
+ [VECS] = GEN8_VTCR,
+ [BCS] = GEN8_BTCR,
+ };
+ enum intel_ring_id id;
+
+ if (INTEL_INFO(dev_priv)->gen < 8)
+ return;
+
+ mutex_lock(&dev_priv->tlb_invalidate_lock);
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ for (id = 0; id < I915_NUM_RINGS; id++) {
+ struct intel_engine_cs *engine = &dev_priv->ring[id];
+ /*
+ * HW architecture suggest typical invalidation time at 40us,
+ * with pessimistic cases up to 100us and a recommendation to
+ * cap at 1ms. We go a bit higher just in case.
+ */
+ const unsigned int timeout_us = 100;
+ const unsigned int timeout_ms = 4;
+
+ if (!intel_ring_initialized(engine))
+ continue;
+
+ if (WARN_ON_ONCE(id >= ARRAY_SIZE(gen8_regs) || !gen8_regs[id]))
+ continue;
+
+ I915_WRITE_FW(gen8_regs[id], 1);
+ if (__intel_wait_for_register_fw(dev_priv,
+ gen8_regs[id], 1, 0,
+ timeout_us, timeout_ms))
+ DRM_ERROR_RATELIMITED("%s TLB invalidation did not complete in %ums!\n",
+ engine->name, timeout_ms);
+ }
+
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ mutex_unlock(&dev_priv->tlb_invalidate_lock);
+}
+
int
i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
{
@@ -2230,6 +2309,14 @@ i915_gem_object_put_pages(struct drm_i91
* lists early. */
list_del(&obj->global_list);
+ if (test_and_clear_bit(I915_BO_WAS_BOUND_BIT, &obj->flags)) {
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ intel_runtime_pm_get(i915);
+ invalidate_tlbs(i915);
+ intel_runtime_pm_put(i915);
+ }
+
ops->put_pages(obj);
obj->pages = NULL;
@@ -5050,6 +5137,8 @@ i915_gem_load(struct drm_device *dev)
i915_gem_shrinker_init(dev_priv);
mutex_init(&dev_priv->fb_tracking.lock);
+
+ mutex_init(&dev_priv->tlb_invalidate_lock);
}
void i915_gem_release(struct drm_device *dev, struct drm_file *file)
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3538,6 +3538,9 @@ int i915_vma_bind(struct i915_vma *vma,
vma->bound |= bind_flags;
+ if (vma->obj)
+ set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
+
return 0;
}
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1592,6 +1592,12 @@ enum skl_disp_power_wells {
#define GEN7_TLB_RD_ADDR 0x4700
+#define GEN8_RTCR 0x4260
+#define GEN8_M1TCR 0x4264
+#define GEN8_M2TCR 0x4268
+#define GEN8_BTCR 0x426c
+#define GEN8_VTCR 0x4270
+
#if 0
#define PRB0_TAIL 0x02030
#define PRB0_HEAD 0x02034
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 4.4 0/1] 4.4.301-rc1 review
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.4 1/1] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
@ 2022-01-27 19:43 ` Pavel Machek
2022-01-28 1:19 ` Shuah Khan
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Pavel Machek @ 2022-01-27 19:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi!
> This is the start of the stable review cycle for the 4.4.301 release.
> There are 1 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 4.4 0/1] 4.4.301-rc1 review
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.4 1/1] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
2022-01-27 19:43 ` [PATCH 4.4 0/1] 4.4.301-rc1 review Pavel Machek
@ 2022-01-28 1:19 ` Shuah Khan
2022-01-28 11:18 ` Jon Hunter
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Shuah Khan @ 2022-01-28 1:19 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, sudipm.mukherjee, Shuah Khan
On 1/27/22 11:08 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.301 release.
> There are 1 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.301-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 4.4 0/1] 4.4.301-rc1 review
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-01-28 1:19 ` Shuah Khan
@ 2022-01-28 11:18 ` Jon Hunter
2022-01-29 1:04 ` Guenter Roeck
2022-01-29 9:38 ` Naresh Kamboju
5 siblings, 0 replies; 7+ messages in thread
From: Jon Hunter @ 2022-01-28 11:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
linux-tegra
On Thu, 27 Jan 2022 19:08:13 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.301 release.
> There are 1 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.301-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
30 tests: 30 pass, 0 fail
Linux version: 4.4.301-rc1-g187d7c3b8ca0
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 4.4 0/1] 4.4.301-rc1 review
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-01-28 11:18 ` Jon Hunter
@ 2022-01-29 1:04 ` Guenter Roeck
2022-01-29 9:38 ` Naresh Kamboju
5 siblings, 0 replies; 7+ messages in thread
From: Guenter Roeck @ 2022-01-29 1:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee
On Thu, Jan 27, 2022 at 07:08:13PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.301 release.
> There are 1 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 160 pass: 160 fail: 0
Qemu test results:
total: 342 pass: 342 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 4.4 0/1] 4.4.301-rc1 review
2022-01-27 18:08 [PATCH 4.4 0/1] 4.4.301-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-01-29 1:04 ` Guenter Roeck
@ 2022-01-29 9:38 ` Naresh Kamboju
5 siblings, 0 replies; 7+ messages in thread
From: Naresh Kamboju @ 2022-01-29 9:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee
On Thu, 27 Jan 2022 at 23:38, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.4.301 release.
> There are 1 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.301-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 4.4.301-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.4.y
* git commit: 187d7c3b8ca09131c71f6dbb8c8761f7f809402c
* git describe: v4.4.300-2-g187d7c3b8ca0
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.300-2-g187d7c3b8ca0
## Test Regressions (compared to v4.4.299-114-g67ca9c44f63d)
No test regressions found.
## Metric Regressions (compared to v4.4.299-114-g67ca9c44f63d)
No metric regressions found.
## Test Fixes (compared to v4.4.299-114-g67ca9c44f63d)
No test fixes found.
## Metric Fixes (compared to v4.4.299-114-g67ca9c44f63d)
No metric fixes found.
## Test result summary
total: 33090, pass: 26341, fail: 104, skip: 5946, xfail: 699
## Build Summary
* arm: 129 total, 129 passed, 0 failed
* arm64: 31 total, 31 passed, 0 failed
* i386: 18 total, 18 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 30 total, 24 passed, 6 failed
## Test suites summary
* kselftest-bpf
* kselftest-intel_pstate
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-zram
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 7+ messages in thread