RE: [PATCH] drm/ttm: Implement strict NUMA pool allocations
>-Original Message-
>From: dri-devel On Behalf Of
>Rajneesh Bhardwaj
>Sent: Friday, March 22, 2024 3:08 AM
>To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: felix.kuehl...@amd.com; alexander.deuc...@amd.com;
>christian.koe...@amd.com; Rajneesh Bhardwaj
>; Joe Greathouse
>
>Subject: [PATCH] drm/ttm: Implement strict NUMA pool allocations
>
>This change allows TTM to be flexible to honor NUMA localized
>allocations which can result in significant performance improvement on a
>multi socket NUMA system. On GFXIP 9.4.3 based AMD APUs, we see
>manyfold benefits of this change resulting not only in ~10% performance
>improvement in certain benchmarks but also generating more consistent
>and less sporadic results specially when the NUMA balancing is not
>explecitely disabled. In certain scenarios, workloads show a run-to-run
>variability e.g. HPL would show a ~10x performance drop after running
>back to back 4-5 times and would recover later on a subsequent run. This
>is seen with memory intensive other workloads too. It was seen that when
>CPU caches were dropped e.g. sudo sysctl -w vm.drop_caches=1, the
>variability reduced but the performance was still well below a good run.
>
>Use of __GFP_THISNODE flag ensures that during memory allocation, kernel
>prioritizes memory allocations from the local or closest NUMA node
>thereby reducing memory access latency. When memory is allocated using
>__GFP_THISNODE flag, memory allocations will predominantly be done on
>the local node, consequency, the shrinkers may priotitize reclaiming
>memory from caches assocoated with local node to maintain memory
>locality and minimize latency, thereby provide better shinker targeting.
>
>Reduced memory pressure on remote nodes, can also indirectly influence
>shrinker behavior by potentially reducing the frequency and intensity of
>memory reclamation operation on remote nodes and could provide improved
>overall system performance.
>
>While this change could be more beneficial in general, i.e., without the
>use of a module parameter, but in absence of widespread testing, limit
>it to the AMD GFXIP 9.4.3 based ttm pool initializations only.
>
>
>Cc: Joe Greathouse
>Signed-off-by: Rajneesh Bhardwaj
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
> drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 10 +-
> drivers/gpu/drm/ttm/ttm_device.c | 2 +-
> drivers/gpu/drm/ttm/ttm_pool.c| 7 ++-
> include/drm/ttm/ttm_pool.h| 4 +++-
> 7 files changed, 30 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>index 9c62552bec34..96532cfc6230 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>@@ -253,6 +253,7 @@ extern int amdgpu_user_partt_mode;
> extern int amdgpu_agp;
>
> extern int amdgpu_wbrf;
>+extern bool strict_numa_alloc;
>
> #define AMDGPU_VM_MAX_NUM_CTX 4096
> #define AMDGPU_SG_THRESHOLD (256*1024*1024)
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>index 80b9642f2bc4..a183a6b4493d 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>@@ -781,6 +781,14 @@ int queue_preemption_timeout_ms = 9000;
> module_param(queue_preemption_timeout_ms, int, 0644);
> MODULE_PARM_DESC(queue_preemption_timeout_ms, "queue preemption
>timeout in ms (1 = Minimum, 9000 = default)");
>
>+/**
>+ * DOC: strict_numa_alloc(bool)
>+ * Policy to force NUMA allocation requests from the proximity NUMA domain
>only.
>+ */
>+bool strict_numa_alloc;
>+module_param(strict_numa_alloc, bool, 0444);
>+MODULE_PARM_DESC(strict_numa_alloc, "Force NUMA allocation requests
>to be satisfied from the closest node only (false = default)");
>+
> /**
> * DOC: debug_evictions(bool)
> * Enable extra debug messages to help determine the cause of evictions
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index b0ed10f4de60..a9f78f85e28c 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -1768,6 +1768,7 @@ static int amdgpu_ttm_reserve_tmr(struct
>amdgpu_device *adev)
>
> static int amdgpu_ttm_pools_init(struct amdgpu_device *adev)
> {
>+ bool policy = true;
> int i;
>
> if (!adev->gmc.is_app_apu || !adev->gmc.num_mem_partitions)
>@@ -1779,11 +1780,15 @@ static int amdgpu_ttm_pools_init(struct
>amdgpu_device *adev)
> if (!adev->mman.ttm_pools)
> return -ENOMEM;
>
>+ /* Policy not only depends on the module param but also on the ASIC
>+ * setting use_strict_numa_alloc as well.
>+ */
> for (i = 0; i < adev->gmc.num_mem_partitions; i++) {
> ttm_pool_init(>mman.ttm_pools[i],
RE: [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an error
>-Original Message-
>From: Aravind Iddamsetty
>Sent: Friday, October 20, 2023 11:59 AM
>To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>alexander.deuc...@amd.com; airl...@gmail.com; dan...@ffwll.ch;
>joonas.lahti...@linux.intel.com; ogab...@kernel.org; Tayar, Tomer (Habana)
>; hawking.zh...@amd.com;
>harish.kasiviswanat...@amd.com; felix.kuehl...@amd.com;
>luben.tui...@amd.com; Ruhl, Michael J
>Subject: [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an
>error
>
>Whenever a correctable or an uncorrectable error happens an event is sent
>to the corresponding listeners of these groups.
>
>v2: Rebase
Hi Aravind,
This looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Aravind Iddamsetty
>---
> drivers/gpu/drm/xe/xe_hw_error.c | 33
>
> 1 file changed, 33 insertions(+)
>
>diff --git a/drivers/gpu/drm/xe/xe_hw_error.c
>b/drivers/gpu/drm/xe/xe_hw_error.c
>index bab6d4cf0b69..b0befb5e01cb 100644
>--- a/drivers/gpu/drm/xe/xe_hw_error.c
>+++ b/drivers/gpu/drm/xe/xe_hw_error.c
>@@ -786,6 +786,37 @@ xe_soc_hw_error_handler(struct xe_tile *tile, const
>enum hardware_error hw_err)
> (HARDWARE_ERROR_MAX << 1) + 1);
> }
>
>+static void
>+generate_netlink_event(struct xe_device *xe, const enum hardware_error
>hw_err)
>+{
>+ struct sk_buff *msg;
>+ void *hdr;
>+
>+ if (!xe->drm.drm_genl_family.module)
>+ return;
>+
>+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
>+ if (!msg) {
>+ drm_dbg_driver(>drm, "couldn't allocate memory for error
>multicast event\n");
>+ return;
>+ }
>+
>+ hdr = genlmsg_put(msg, 0, 0, >drm.drm_genl_family, 0,
>DRM_RAS_CMD_ERROR_EVENT);
>+ if (!hdr) {
>+ drm_dbg_driver(>drm, "mutlicast msg buffer is small\n");
>+ nlmsg_free(msg);
>+ return;
>+ }
>+
>+ genlmsg_end(msg, hdr);
>+
>+ genlmsg_multicast(>drm.drm_genl_family, msg, 0,
>+hw_err ?
>+DRM_GENL_MCAST_UNCORR_ERR
>+: DRM_GENL_MCAST_CORR_ERR,
>+GFP_ATOMIC);
>+}
>+
> static void
> xe_hw_error_source_handler(struct xe_tile *tile, const enum hardware_error
>hw_err)
> {
>@@ -849,6 +880,8 @@ xe_hw_error_source_handler(struct xe_tile *tile, const
>enum hardware_error hw_er
> }
>
> xe_mmio_write32(gt, DEV_ERR_STAT_REG(hw_err), errsrc);
>+
>+ generate_netlink_event(tile_to_xe(tile), hw_err);
> unlock:
> spin_unlock_irqrestore(_to_xe(tile)->irq.lock, flags);
> }
>--
>2.25.1
RE: [RFC 4/5] drm/netlink: Define multicast groups
>-Original Message-
>From: Aravind Iddamsetty
>Sent: Friday, October 20, 2023 11:59 AM
>To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>alexander.deuc...@amd.com; airl...@gmail.com; dan...@ffwll.ch;
>joonas.lahti...@linux.intel.com; ogab...@kernel.org; Tayar, Tomer (Habana)
>; hawking.zh...@amd.com;
>harish.kasiviswanat...@amd.com; felix.kuehl...@amd.com;
>luben.tui...@amd.com; Ruhl, Michael J
>Subject: [RFC 4/5] drm/netlink: Define multicast groups
>
>Netlink subsystem supports event notifications to userspace. we define
>two multicast groups for correctable and uncorrectable errors to which
>userspace can subscribe and be notified when any of those errors happen.
>The group names are local to the driver's genl netlink family.
Hi Aravind,
This looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Aravind Iddamsetty
>---
> drivers/gpu/drm/drm_netlink.c | 7 +++
> include/drm/drm_netlink.h | 5 +
> include/uapi/drm/drm_netlink.h | 4
> 3 files changed, 16 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_netlink.c b/drivers/gpu/drm/drm_netlink.c
>index 8add249c1da3..425a7355a573 100644
>--- a/drivers/gpu/drm/drm_netlink.c
>+++ b/drivers/gpu/drm/drm_netlink.c
>@@ -12,6 +12,11 @@
>
> DEFINE_XARRAY(drm_dev_xarray);
>
>+static const struct genl_multicast_group drm_event_mcgrps[] = {
>+ [DRM_GENL_MCAST_CORR_ERR] = { .name =
>DRM_GENL_MCAST_GROUP_NAME_CORR_ERR, },
>+ [DRM_GENL_MCAST_UNCORR_ERR] = { .name =
>DRM_GENL_MCAST_GROUP_NAME_UNCORR_ERR, },
>+};
>+
> /**
> * drm_genl_reply - response to a request
> * @msg: socket buffer
>@@ -133,6 +138,8 @@ static void drm_genl_family_init(struct drm_device
>*dev)
> dev->drm_genl_family.ops = drm_genl_ops;
> dev->drm_genl_family.n_ops = ARRAY_SIZE(drm_genl_ops);
> dev->drm_genl_family.maxattr = DRM_ATTR_MAX;
>+ dev->drm_genl_family.mcgrps = drm_event_mcgrps;
>+ dev->drm_genl_family.n_mcgrps = ARRAY_SIZE(drm_event_mcgrps);
> dev->drm_genl_family.module = dev->dev->driver->owner;
> }
>
>diff --git a/include/drm/drm_netlink.h b/include/drm/drm_netlink.h
>index 54527dae7847..758239643c17 100644
>--- a/include/drm/drm_netlink.h
>+++ b/include/drm/drm_netlink.h
>@@ -13,6 +13,11 @@
>
> struct drm_device;
>
>+enum mcgrps_events {
>+ DRM_GENL_MCAST_CORR_ERR,
>+ DRM_GENL_MCAST_UNCORR_ERR,
>+};
>+
> struct driver_genl_ops {
> int(*doit)(struct drm_device *dev,
> struct sk_buff *skb,
>diff --git a/include/uapi/drm/drm_netlink.h b/include/uapi/drm/drm_netlink.h
>index aab42147a20e..c7a0ce5b4624 100644
>--- a/include/uapi/drm/drm_netlink.h
>+++ b/include/uapi/drm/drm_netlink.h
>@@ -26,6 +26,8 @@
> #define _DRM_NETLINK_H_
>
> #define DRM_GENL_VERSION 1
>+#define DRM_GENL_MCAST_GROUP_NAME_CORR_ERR"drm_corr_err"
>+#define DRM_GENL_MCAST_GROUP_NAME_UNCORR_ERR
> "drm_uncorr_err"
>
> #if defined(__cplusplus)
> extern "C" {
>@@ -43,6 +45,8 @@ enum drm_genl_error_cmds {
> DRM_RAS_CMD_READ_ONE,
> /** @DRM_RAS_CMD_READ_ALL: Command to get counters of all
>errors */
> DRM_RAS_CMD_READ_ALL,
>+ /** @DRM_RAS_CMD_ERROR_EVENT: Command sent as part of
>multicast event */
>+ DRM_RAS_CMD_ERROR_EVENT,
>
> __DRM_CMD_MAX,
> DRM_CMD_MAX = __DRM_CMD_MAX - 1,
>--
>2.25.1
RE: [RFC v3 3/5] drm/xe/RAS: Expose the error counters
>-Original Message-
>From: Aravind Iddamsetty
>Sent: Friday, October 20, 2023 11:59 AM
>To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>alexander.deuc...@amd.com; airl...@gmail.com; dan...@ffwll.ch;
>joonas.lahti...@linux.intel.com; ogab...@kernel.org; Tayar, Tomer (Habana)
>; hawking.zh...@amd.com;
>harish.kasiviswanat...@amd.com; felix.kuehl...@amd.com;
>luben.tui...@amd.com; Ruhl, Michael J
>Subject: [RFC v3 3/5] drm/xe/RAS: Expose the error counters
>
>We expose the various error counters supported on a hardware via genl
>subsytem through the registered commands to userspace. The
>DRM_RAS_CMD_QUERY lists the error names with config id,
>DRM_RAD_CMD_READ_ONE returns the counter value for the requested config
>id and the DRM_RAS_CMD_READ_ALL lists the counters for all errors along
>with their names and config ids.
>
>v2: Rebase
>
>v3:
>1. presently xe_list_errors fills blank data for IGFX, prevent it by
>having an early check of IS_DGFX (Michael J. Ruhl)
>2. update errors from all sources
Hi Aravind,
This looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
>Cc: Ruhl, Michael J
>Signed-off-by: Aravind Iddamsetty
>---
> drivers/gpu/drm/xe/xe_netlink.c | 499
>+++-
> include/uapi/drm/xe_drm.h | 81 ++
> 2 files changed, 578 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/xe/xe_netlink.c b/drivers/gpu/drm/xe/xe_netlink.c
>index 81d785455632..3e4cdb5e4920 100644
>--- a/drivers/gpu/drm/xe/xe_netlink.c
>+++ b/drivers/gpu/drm/xe/xe_netlink.c
>@@ -2,16 +2,511 @@
> /*
> * Copyright © 2023 Intel Corporation
> */
>+#include
>+
> #include "xe_device.h"
>
>-static int xe_genl_list_errors(struct drm_device *drm, struct sk_buff *msg,
>struct genl_info *info)
>+#define MAX_ERROR_NAME100
>+
>+static const char * const xe_hw_error_events[] = {
>+ [XE_GENL_GT_ERROR_CORRECTABLE_L3_SNG] = "correctable-
>l3-sng",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_GUC] = "correctable-
>guc",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_SAMPLER] =
>"correctable-sampler",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_SLM] = "correctable-
>slm",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_EU_IC] = "correctable-
>eu-ic",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_EU_GRF] = "correctable-
>eu-grf",
>+ [XE_GENL_GT_ERROR_FATAL_ARR_BIST] = "fatal-array-bist",
>+ [XE_GENL_GT_ERROR_FATAL_L3_DOUB] = "fatal-l3-double",
>+ [XE_GENL_GT_ERROR_FATAL_L3_ECC_CHK] = "fatal-l3-ecc-
>checker",
>+ [XE_GENL_GT_ERROR_FATAL_GUC] = "fatal-guc",
>+ [XE_GENL_GT_ERROR_FATAL_IDI_PAR] = "fatal-idi-parity",
>+ [XE_GENL_GT_ERROR_FATAL_SQIDI] = "fatal-sqidi",
>+ [XE_GENL_GT_ERROR_FATAL_SAMPLER] = "fatal-sampler",
>+ [XE_GENL_GT_ERROR_FATAL_SLM] = "fatal-slm",
>+ [XE_GENL_GT_ERROR_FATAL_EU_IC] = "fatal-eu-ic",
>+ [XE_GENL_GT_ERROR_FATAL_EU_GRF] = "fatal-eu-grf",
>+ [XE_GENL_GT_ERROR_FATAL_FPU] = "fatal-fpu",
>+ [XE_GENL_GT_ERROR_FATAL_TLB] = "fatal-tlb",
>+ [XE_GENL_GT_ERROR_FATAL_L3_FABRIC] = "fatal-l3-fabric",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_SUBSLICE] =
>"correctable-subslice",
>+ [XE_GENL_GT_ERROR_CORRECTABLE_L3BANK] = "correctable-
>l3bank",
>+ [XE_GENL_GT_ERROR_FATAL_SUBSLICE] = "fatal-subslice",
>+ [XE_GENL_GT_ERROR_FATAL_L3BANK] = "fatal-l3bank",
>+ [XE_GENL_SGUNIT_ERROR_CORRECTABLE] = "sgunit-
>correctable",
>+ [XE_GENL_SGUNIT_ERROR_NONFATAL] = "sgunit-nonfatal",
>+ [XE_GENL_SGUNIT_ERROR_FATAL] = "sgunit-fatal",
>+ [XE_GENL_SOC_ERROR_NONFATAL_CSC_PSF_CMD] = "soc-
>nonfatal-csc-psf-cmd-parity",
>+ [XE_GENL_SOC_ERROR_NONFATAL_CSC_PSF_CMP] = "soc-
>nonfatal-csc-psf-unexpected-completion",
>+ [XE_GENL_SOC_ERROR_NONFATAL_CSC_PSF_REQ] = "soc-
>nonfatal-csc-psf-unsupported-request",
>+ [XE_GENL_SOC_ERROR_NONFATAL_ANR_MDFI] = "soc-
>nonfatal-anr-mdfi",
>+ [XE_GENL_SOC_ERROR_NONFATAL_MDFI_T2T] = "soc-
>nonfatal-mdfi-t2t",
>+ [XE_GENL_SOC_ERROR_NONFATAL_MDFI_T2C] = "soc-
>nonfatal-mdfi-t2c",
>+ [XE_GENL_SOC_ERROR_NONFATAL_HBM(0, 0)] = "soc-
>nonfatal-hbm-ss0-0",
>+
RE: [RFC v2 2/5] drm/xe/RAS: Register netlink capability
>-Original Message-
>From: Aravind Iddamsetty
>Sent: Friday, October 20, 2023 11:59 AM
>To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>alexander.deuc...@amd.com; airl...@gmail.com; dan...@ffwll.ch;
>joonas.lahti...@linux.intel.com; ogab...@kernel.org; Tayar, Tomer (Habana)
>; hawking.zh...@amd.com;
>harish.kasiviswanat...@amd.com; felix.kuehl...@amd.com;
>luben.tui...@amd.com; Ruhl, Michael J
>Subject: [RFC v2 2/5] drm/xe/RAS: Register netlink capability
>
>Register netlink capability with the DRM and register the driver
>callbacks to DRM RAS netlink commands.
>
>v2:
>Move the netlink registration parts to DRM susbsytem (Tomer Tayar)
>
>Cc: Tomer Tayar
>Signed-off-by: Aravind Iddamsetty
>---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_device.c | 4
> drivers/gpu/drm/xe/xe_device_types.h | 1 +
> drivers/gpu/drm/xe/xe_netlink.c | 22 ++
> 4 files changed, 28 insertions(+)
> create mode 100644 drivers/gpu/drm/xe/xe_netlink.c
>
>diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>index ed772f440689..048f9a23e2f0 100644
>--- a/drivers/gpu/drm/xe/Makefile
>+++ b/drivers/gpu/drm/xe/Makefile
>@@ -87,6 +87,7 @@ xe-y += xe_bb.o \
> xe_mmio.o \
> xe_mocs.o \
> xe_module.o \
>+ xe_netlink.o \
> xe_pat.o \
> xe_pci.o \
> xe_pcode.o \
>diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
>index 628cb46a2509..8c928719a537 100644
>--- a/drivers/gpu/drm/xe/xe_device.c
>+++ b/drivers/gpu/drm/xe/xe_device.c
>@@ -151,6 +151,8 @@ static void xe_driver_release(struct drm_device *dev)
> pci_set_drvdata(to_pci_dev(xe->drm.dev), NULL);
> }
>
>+extern const struct driver_genl_ops xe_genl_ops[];
>+
> static struct drm_driver driver = {
> /* Don't use MTRRs here; the Xserver or userspace app should
>* deal with them for Intel hardware.
>@@ -159,6 +161,7 @@ static struct drm_driver driver = {
> DRIVER_GEM |
> DRIVER_RENDER | DRIVER_SYNCOBJ |
> DRIVER_SYNCOBJ_TIMELINE | DRIVER_GEM_GPUVA,
>+
Gratuitous blank line?
With or without this cleaned up:
This looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
> .open = xe_file_open,
> .postclose = xe_file_close,
>
>@@ -170,6 +173,7 @@ static struct drm_driver driver = {
> .show_fdinfo = xe_drm_client_fdinfo,
> #endif
> .release = _driver_release,
>+ .genl_ops = xe_genl_ops,
>
> .ioctls = xe_ioctls,
> .num_ioctls = ARRAY_SIZE(xe_ioctls),
>diff --git a/drivers/gpu/drm/xe/xe_device_types.h
>b/drivers/gpu/drm/xe/xe_device_types.h
>index a1bacf820d37..8201f3644b86 100644
>--- a/drivers/gpu/drm/xe/xe_device_types.h
>+++ b/drivers/gpu/drm/xe/xe_device_types.h
>@@ -10,6 +10,7 @@
>
> #include
> #include
>+#include
> #include
>
> #include "xe_devcoredump_types.h"
>diff --git a/drivers/gpu/drm/xe/xe_netlink.c b/drivers/gpu/drm/xe/xe_netlink.c
>new file mode 100644
>index ..81d785455632
>--- /dev/null
>+++ b/drivers/gpu/drm/xe/xe_netlink.c
>@@ -0,0 +1,22 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright © 2023 Intel Corporation
>+ */
>+#include "xe_device.h"
>+
>+static int xe_genl_list_errors(struct drm_device *drm, struct sk_buff *msg,
>struct genl_info *info)
>+{
>+ return 0;
>+}
>+
>+static int xe_genl_read_error(struct drm_device *drm, struct sk_buff *msg,
>struct genl_info *info)
>+{
>+ return 0;
>+}
>+
>+/* driver callbacks to DRM netlink commands*/
>+const struct driver_genl_ops xe_genl_ops[] = {
>+ [DRM_RAS_CMD_QUERY] = { .doit = xe_genl_list_errors },
>+ [DRM_RAS_CMD_READ_ONE] ={ .doit = xe_genl_read_error },
>+ [DRM_RAS_CMD_READ_ALL] ={ .doit = xe_genl_list_errors, },
>+};
>--
>2.25.1
RE: [RFC v4 1/5] drm/netlink: Add netlink infrastructure
>-Original Message-
>From: Aravind Iddamsetty
>Sent: Friday, October 20, 2023 11:59 AM
>To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>alexander.deuc...@amd.com; airl...@gmail.com; dan...@ffwll.ch;
>joonas.lahti...@linux.intel.com; ogab...@kernel.org; Tayar, Tomer (Habana)
>; hawking.zh...@amd.com;
>harish.kasiviswanat...@amd.com; felix.kuehl...@amd.com;
>luben.tui...@amd.com; Ruhl, Michael J
>Subject: [RFC v4 1/5] drm/netlink: Add netlink infrastructure
>
>Define the netlink registration interface and commands, attributes that
>can be commonly used across by drm drivers. This patch intends to use
>the generic netlink family to expose various stats of device. At present
>it defines some commands that shall be used to expose RAS error counters.
>
>v2:
>define common interfaces to genl netlink subsystem that all drm drivers
>can leverage.(Tomer Tayar)
>
>v3: drop DRIVER_NETLINK flag and use the driver_genl_ops structure to
>register to netlink subsystem (Daniel Vetter)
>
>v4:(Michael J. Ruhl)
>1. rename drm_genl_send to drm_genl_reply
>2. catch error from xa_store and handle appropriately
Hi Aravind,
This looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
>Cc: Tomer Tayar
>Cc: Daniel Vetter
>Cc: Michael J. Ruhl
>
>Signed-off-by: Aravind Iddamsetty
>---
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_drv.c | 7 ++
> drivers/gpu/drm/drm_netlink.c | 188
>+
> include/drm/drm_device.h | 8 ++
> include/drm/drm_drv.h | 7 ++
> include/drm/drm_netlink.h | 30 ++
> include/uapi/drm/drm_netlink.h | 83 +++
> 7 files changed, 324 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_netlink.c
> create mode 100644 include/drm/drm_netlink.h
> create mode 100644 include/uapi/drm/drm_netlink.h
>
>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>index ee64c51274ad..60864369adaa 100644
>--- a/drivers/gpu/drm/Makefile
>+++ b/drivers/gpu/drm/Makefile
>@@ -35,6 +35,7 @@ drm-y := \
> drm_mode_object.o \
> drm_modes.o \
> drm_modeset_lock.o \
>+ drm_netlink.o \
> drm_plane.o \
> drm_prime.o \
> drm_print.o \
>diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>index 535f16e7882e..31f55c1c7524 100644
>--- a/drivers/gpu/drm/drm_drv.c
>+++ b/drivers/gpu/drm/drm_drv.c
>@@ -937,6 +937,12 @@ int drm_dev_register(struct drm_device *dev,
>unsigned long flags)
> if (ret)
> goto err_minors;
>
>+ if (driver->genl_ops) {
>+ ret = drm_genl_register(dev);
>+ if (ret)
>+ goto err_minors;
>+ }
>+
> ret = create_compat_control_link(dev);
> if (ret)
> goto err_minors;
>@@ -1074,6 +1080,7 @@ static void drm_core_exit(void)
> {
> drm_privacy_screen_lookup_exit();
> accel_core_exit();
>+ drm_genl_exit();
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
>diff --git a/drivers/gpu/drm/drm_netlink.c b/drivers/gpu/drm/drm_netlink.c
>new file mode 100644
>index ..8add249c1da3
>--- /dev/null
>+++ b/drivers/gpu/drm/drm_netlink.c
>@@ -0,0 +1,188 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright © 2023 Intel Corporation
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+DEFINE_XARRAY(drm_dev_xarray);
>+
>+/**
>+ * drm_genl_reply - response to a request
>+ * @msg: socket buffer
>+ * @info: receiver information
>+ * @usrhdr: pointer to user specific header in the message buffer
>+ *
>+ * RETURNS:
>+ * 0 on success and negative error code on failure
>+ */
>+int drm_genl_reply(struct sk_buff *msg, struct genl_info *info, void *usrhdr)
>+{
>+ int ret;
>+
>+ genlmsg_end(msg, usrhdr);
>+
>+ ret = genlmsg_reply(msg, info);
>+ if (ret)
>+ nlmsg_free(msg);
>+
>+ return ret;
>+}
>+EXPORT_SYMBOL(drm_genl_reply);
>+
>+/**
>+ * drm_genl_alloc_msg - allocate genl message buffer
>+ * @dev: drm_device for which the message is being allocated
>+ * @info: receiver information
>+ * @usrhdr: pointer to user specific header in the message buffer
>+ *
>+ * RETURNS:
>+ * pointer to new allocated buffer on success, NULL on failure
>+ */
>+struct sk_buff *
>+drm_genl_alloc_msg(struct drm_device *dev,
>+ struct genl_info *info,
>+ size_t msg_size, void **usrhdr)
>+{
>+ struct sk_buff *new_msg;
>+ new_msg = genlmsg_new(
RE: Implement svm without BO concept in xe driver
>-Original Message- >From: Felix Kuehling >Sent: Monday, August 21, 2023 4:57 PM >To: Zeng, Oak ; Dave Airlie >Cc: Brost, Matthew ; Thomas Hellström >; Philip Yang ; >Welty, Brian ; dri-devel@lists.freedesktop.org; >Christian König ; Vishwanathapura, Niranjana >; intel...@lists.freedesktop.org; >Ruhl, Michael J >Subject: Re: Implement svm without BO concept in xe driver > > >On 2023-08-21 15:41, Zeng, Oak wrote: >>> I have thought about emulating BO allocation APIs on top of system SVM. >>> This was in the context of KFD where memory management is not tied into >>> command submissions APIs, which would add a whole other layer of >>> complexity. The main unsolved (unsolvable?) problem I ran into was, that >>> there is no way to share SVM memory as DMABufs. So there is no good >way >>> to support applications that expect to share memory in that way. >> Great point. I also discussed the dmabuf thing with Mike (cc'ed). dmabuf is a >particular technology created specially for the BO driver (and other driver) to >share buffer b/t devices. Hmm/system SVM doesn't need this technology: >malloc'ed memory by the nature is already shared b/t different devices (in >one process) and CPU. We just can simply submit GPU kernel to all devices >with malloc'ed memory and let kmd decide the memory placement (such as >map in place or migrate). No need of buffer export/import in hmm/system >SVM world. > >I disagree. DMABuf can be used for sharing memory between processes. And >it can be used for sharing memory with 3rd-party devices via PCIe P2P >(e.g. a Mellanox NIC). You cannot easily do that with malloc'ed memory. >POSIX IPC requires that you know that you'll be sharing the memory at >allocation time. It adds overhead. And because it's file-backed, it's >currently incompatible with migration. And HMM currently doesn't have a >solution for P2P. Any access by a different device causes a migration to >system memory. Hey Oak, I think we were discussing this solution in the context of using the P2P_DMA feature. This has an allocation path and a device 2 device capabilities. Mike >Regards, > Felix > > >> >> So yes from buffer sharing perspective, the design philosophy is also very >different. >> >> Thanks, >> Oak >>
RE: [PATCH v2 01/38] backlight/bd6107: Compare against struct fb_info.device
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Monday, June 12, 2023 10:08 AM
>To: dan...@ffwll.ch; javi...@redhat.com; s...@ravnborg.org;
>del...@gmx.de; geert+rene...@glider.be; l...@kernel.org;
>daniel.thomp...@linaro.org; jingooh...@gmail.com;
>dan.carpen...@linaro.org; Ruhl, Michael J
>Cc: linux-fb...@vger.kernel.org; Laurent Pinchart
>; linux...@vger.kernel.org;
>linux-stag...@lists.linux.dev; linux-ker...@vger.kernel.org; dri-
>de...@lists.freedesktop.org; sta...@vger.kernel.org; Thomas Zimmermann
>; linux-o...@vger.kernel.org
>Subject: [PATCH v2 01/38] backlight/bd6107: Compare against struct
>fb_info.device
>
>Struct bd6107_platform_data refers to a platform device within
>the Linux device hierarchy. The test in bd6107_backlight_check_fb()
>compares it against the fbdev device in struct fb_info.dev, which
>is different. Fix the test by comparing to struct fb_info.device.
>
>Fixes a bug in the backlight driver and prepares fbdev for making
>struct fb_info.dev optional.
>
>v2:
> * move renames into separate patch (Javier, Sam, Michael)
>
>Fixes: 67b43e590415 ("backlight: Add ROHM BD6107 backlight driver")
>Signed-off-by: Thomas Zimmermann
>Cc: Laurent Pinchart
>Cc: Lee Jones
>Cc: Daniel Thompson
>Cc: Jingoo Han
>Cc: dri-devel@lists.freedesktop.org
>Cc: # v3.12+
>Reviewed-by: Javier Martinez Canillas
>---
> drivers/video/backlight/bd6107.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/video/backlight/bd6107.c
>b/drivers/video/backlight/bd6107.c
>index f4db6c064635b..e3410444ea235 100644
>--- a/drivers/video/backlight/bd6107.c
>+++ b/drivers/video/backlight/bd6107.c
>@@ -104,7 +104,7 @@ static int bd6107_backlight_check_fb(struct
>backlight_device *backlight,
> {
> struct bd6107 *bd = bl_get_data(backlight);
>
>- return bd->pdata->fbdev == NULL || bd->pdata->fbdev == info->dev;
>+ return bd->pdata->fbdev == NULL || bd->pdata->fbdev == info->device;
Thomas,
Looking at the fb.h file I see:
struct device *device; /* This is the parent */
struct device *dev; /* This is this fb device */
Is this documentation "correct"? If so, how does that match what you are doing
here?
Thanks,
M
> }
>
> static const struct backlight_ops bd6107_backlight_ops = {
>--
>2.41.0
RE: [PATCH 0/3] fbdev/hitfb: Various fixes
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Tuesday, June 6, 2023 6:41 AM
>To: del...@gmx.de; david.lai...@aculab.com
>Cc: linux-fb...@vger.kernel.org; Thomas Zimmermann
>; dri-devel@lists.freedesktop.org; linux-
>s...@vger.kernel.org
>Subject: [PATCH 0/3] fbdev/hitfb: Various fixes
>
>Fix a number of minor warnings in the hitfb driver. I discovered
>them while working on bb47f218fd01 ("fbdev/hitfb: Cast I/O offset
>to address").
>
>Thomas Zimmermann (3):
> fbdev/hitfb: Declare hitfb_blank() as static
> fbdev/hitfb: Fix integer-to-pointer cast
> fbdev/hitfb: Use NULL for pointers
These look reasonable to me.
For the series:
Reviewed-by: Michael J. Ruhl
> drivers/video/fbdev/hitfb.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
>base-commit: 29c0f369e17ba0abf08c65ca065417aebab208c6
>--
>2.40.1
RE: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
>-Original Message-
>From: Sam Ravnborg
>Sent: Monday, June 5, 2023 4:23 PM
>To: Ruhl, Michael J
>Cc: Thomas Zimmermann ; dan...@ffwll.ch;
>javi...@redhat.com; del...@gmx.de; geert+rene...@glider.be;
>l...@kernel.org; daniel.thomp...@linaro.org; jingooh...@gmail.com; linux-
>fb...@vger.kernel.org; Rich Felker ; linux-
>s...@vger.kernel.org; linux-stag...@lists.linux.dev; dri-
>de...@lists.freedesktop.org; John Paul Adrian Glaubitz berlin.de>; linux-o...@vger.kernel.org
>Subject: Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>fb_info.device
>
>Hi Michael.
>
>> >
>> >Fixes a bug in the backlight driver and prepares fbdev for making
>> >struct fb_info.dev optional.
>>
>> I only see a rename from fbdev to dev...
>>
>> Is there missing code?
>>
>> Would a fixes: be useful?
>>
>> M
>>
>> >@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
>> >backlight_device *bl,
>> > {
>> >struct gpio_backlight *gbl = bl_get_data(bl);
>> >
>> >- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
>> >+ return !gbl->dev || gbl->dev == info->device;
>> > }
>
>The real change is here where info->dev is replaced by info->device.
Yeah, after a few patches, I was getting the idea that the name was the bug.
Thanks,
M
> Sam
RE: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Monday, June 5, 2023 10:48 AM
>To: dan...@ffwll.ch; javi...@redhat.com; s...@ravnborg.org;
>del...@gmx.de; geert+rene...@glider.be; l...@kernel.org;
>daniel.thomp...@linaro.org; jingooh...@gmail.com
>Cc: linux-fb...@vger.kernel.org; Rich Felker ; linux-
>s...@vger.kernel.org; linux-stag...@lists.linux.dev; dri-
>de...@lists.freedesktop.org; Thomas Zimmermann
>; John Paul Adrian Glaubitz berlin.de>; linux-o...@vger.kernel.org
>Subject: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>fb_info.device
>
>Struct gpio_backlight_platform_data refers to a platform device within
>the Linux device hierarchy. The test in gpio_backlight_check_fb()
>compares it against the fbdev device in struct fb_info.dev, which
>is different. Fix the test by comparing to struct fb_info.device.
>
>Fixes a bug in the backlight driver and prepares fbdev for making
>struct fb_info.dev optional.
I only see a rename from fbdev to dev...
Is there missing code?
Would a fixes: be useful?
M
>Signed-off-by: Thomas Zimmermann
>Cc: Rich Felker
>Cc: John Paul Adrian Glaubitz
>Cc: Lee Jones
>Cc: Daniel Thompson
>Cc: Jingoo Han
>Cc: linux...@vger.kernel.org
>---
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> drivers/video/backlight/gpio_backlight.c | 6 +++---
> include/linux/platform_data/gpio_backlight.h | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-
>ecovec24/setup.c
>index 674da7ebd8b7..310513646c9b 100644
>--- a/arch/sh/boards/mach-ecovec24/setup.c
>+++ b/arch/sh/boards/mach-ecovec24/setup.c
>@@ -386,7 +386,7 @@ static struct property_entry gpio_backlight_props[] = {
> };
>
> static struct gpio_backlight_platform_data gpio_backlight_data = {
>- .fbdev = _device.dev,
>+ .dev = _device.dev,
> };
>
> static const struct platform_device_info gpio_backlight_device_info = {
>diff --git a/drivers/video/backlight/gpio_backlight.c
>b/drivers/video/backlight/gpio_backlight.c
>index 6f78d928f054..d3bea42407f1 100644
>--- a/drivers/video/backlight/gpio_backlight.c
>+++ b/drivers/video/backlight/gpio_backlight.c
>@@ -17,7 +17,7 @@
> #include
>
> struct gpio_backlight {
>- struct device *fbdev;
>+ struct device *dev;
> struct gpio_desc *gpiod;
> };
>
>@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
>backlight_device *bl,
> {
> struct gpio_backlight *gbl = bl_get_data(bl);
>
>- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
>+ return !gbl->dev || gbl->dev == info->device;
> }
>
> static const struct backlight_ops gpio_backlight_ops = {
>@@ -59,7 +59,7 @@ static int gpio_backlight_probe(struct platform_device
>*pdev)
> return -ENOMEM;
>
> if (pdata)
>- gbl->fbdev = pdata->fbdev;
>+ gbl->dev = pdata->dev;
>
> def_value = device_property_read_bool(dev, "default-on");
>
>diff --git a/include/linux/platform_data/gpio_backlight.h
>b/include/linux/platform_data/gpio_backlight.h
>index 1a8b5b1946fe..323fbf5f7613 100644
>--- a/include/linux/platform_data/gpio_backlight.h
>+++ b/include/linux/platform_data/gpio_backlight.h
>@@ -8,7 +8,7 @@
> struct device;
>
> struct gpio_backlight_platform_data {
>- struct device *fbdev;
>+ struct device *dev;
> };
>
> #endif
>--
>2.40.1
RE: [PATCH] dma-buf: fix dma_buf_export init order v2
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Friday, December 9, 2022 2:16 AM
>To: quic_chara...@quicinc.com; cuigaoshe...@huawei.com;
>sumit.sem...@linaro.org
>Cc: linaro-mm-...@lists.linaro.org; dri-devel@lists.freedesktop.org; linux-
>me...@vger.kernel.org
>Subject: [PATCH] dma-buf: fix dma_buf_export init order v2
>
>The init order and resulting error handling in dma_buf_export
>was pretty messy.
>
>Subordinate objects like the file and the sysfs kernel objects
>were initializing and wiring itself up with the object in the
>wrong order resulting not only in complicating and partially
>incorrect error handling, but also in publishing only halve
>initialized DMA-buf objects.
>
>Clean this up thoughtfully by allocating the file independent
>of the DMA-buf object. Then allocate and initialize the DMA-buf
>object itself, before publishing it through sysfs. If everything
>works as expected the file is then connected with the DMA-buf
>object and publish it through debugfs.
>
>Also adds the missing dma_resv_fini() into the error handling.
>
>v2: add some missing changes to dma_bug_getfile() and a missing NULL
>check in dma_buf_file_release()
Looks good.
Reviewed-by: Michael J. Ruhl
Mike
>Signed-off-by: Christian König
>---
> drivers/dma-buf/dma-buf-sysfs-stats.c | 7 +--
> drivers/dma-buf/dma-buf-sysfs-stats.h | 4 +-
> drivers/dma-buf/dma-buf.c | 84 +--
> 3 files changed, 43 insertions(+), 52 deletions(-)
>
>diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-
>buf-sysfs-stats.c
>index 2bba0babcb62..4b680e10c15a 100644
>--- a/drivers/dma-buf/dma-buf-sysfs-stats.c
>+++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
>@@ -168,14 +168,11 @@ void dma_buf_uninit_sysfs_statistics(void)
> kset_unregister(dma_buf_stats_kset);
> }
>
>-int dma_buf_stats_setup(struct dma_buf *dmabuf)
>+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file)
> {
> struct dma_buf_sysfs_entry *sysfs_entry;
> int ret;
>
>- if (!dmabuf || !dmabuf->file)
>- return -EINVAL;
>-
> if (!dmabuf->exp_name) {
> pr_err("exporter name must not be empty if stats
>needed\n");
> return -EINVAL;
>@@ -192,7 +189,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf)
>
> /* create the directory for buffer stats */
> ret = kobject_init_and_add(_entry->kobj, _buf_ktype,
>NULL,
>- "%lu", file_inode(dmabuf->file)->i_ino);
>+ "%lu", file_inode(file)->i_ino);
> if (ret)
> goto err_sysfs_dmabuf;
>
>diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-
>buf-sysfs-stats.h
>index a49c6e2650cc..7a8a995b75ba 100644
>--- a/drivers/dma-buf/dma-buf-sysfs-stats.h
>+++ b/drivers/dma-buf/dma-buf-sysfs-stats.h
>@@ -13,7 +13,7 @@
> int dma_buf_init_sysfs_statistics(void);
> void dma_buf_uninit_sysfs_statistics(void);
>
>-int dma_buf_stats_setup(struct dma_buf *dmabuf);
>+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file);
>
> void dma_buf_stats_teardown(struct dma_buf *dmabuf);
> #else
>@@ -25,7 +25,7 @@ static inline int dma_buf_init_sysfs_statistics(void)
>
> static inline void dma_buf_uninit_sysfs_statistics(void) {}
>
>-static inline int dma_buf_stats_setup(struct dma_buf *dmabuf)
>+static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file
>*file)
> {
> return 0;
> }
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index e6f36c014c4c..eb6b59363c4f 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -95,10 +95,11 @@ static int dma_buf_file_release(struct inode *inode,
>struct file *file)
> return -EINVAL;
>
> dmabuf = file->private_data;
>-
>- mutex_lock(_list.lock);
>- list_del(>list_node);
>- mutex_unlock(_list.lock);
>+ if (dmabuf) {
>+ mutex_lock(_list.lock);
>+ list_del(>list_node);
>+ mutex_unlock(_list.lock);
>+ }
>
> return 0;
> }
>@@ -523,17 +524,17 @@ static inline int is_dma_buf_file(struct file *file)
> return file->f_op == _buf_fops;
> }
>
>-static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
>+static struct file *dma_buf_getfile(size_t size, int flags)
> {
> static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
>- struct file *file;
> struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
>+ struct file *file;
>
> if (IS_ERR(inode))
> return ERR_CAST(inode);
>
>- inode->i_size = dmabuf->size;
>- inode_set_bytes(inode, dmabuf->size);
>+ inode->i_size = size;
>+ inode_set_bytes(inode, size);
>
> /*
>* The ->i_ino acquired from get_next_ino() is not unique thus
>@@ -547,8 +548,6 @@ static struct file *dma_buf_getfile(struct dma_buf
>*dmabuf, int flags)
>flags, _buf_fops);
RE: [PATCH] dma-buf: fix dma_buf_export init order
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Tuesday, December 6, 2022 10:12 AM
>To: quic_chara...@quicinc.com; cuigaoshe...@huawei.com;
>tjmerc...@google.com; sumit.sem...@linaro.org
>Cc: linaro-mm-...@lists.linaro.org; dri-devel@lists.freedesktop.org; linux-
>me...@vger.kernel.org
>Subject: [PATCH] dma-buf: fix dma_buf_export init order
>
>The init order and resulting error handling in dma_buf_export
>was pretty messy.
>
>Subordinate objects like the file and the sysfs kernel objects
>were initializing and wiring itself up with the object in the
>wrong order resulting not only in complicating and partially
>incorrect error handling, but also in publishing only halve
>initialized DMA-buf objects.
>
>Clean this up thoughtfully by allocating the file independent
>of the DMA-buf object. Then allocate and initialize the DMA-buf
>object itself, before publishing it through sysfs. If everything
>works as expected the file is then connected with the DMA-buf
>object and publish it through debugfs.
>
>Also adds the missing dma_resv_fini() into the error handling.
>
>Signed-off-by: Christian König
>---
> drivers/dma-buf/dma-buf-sysfs-stats.c | 7 +--
> drivers/dma-buf/dma-buf-sysfs-stats.h | 4 +-
> drivers/dma-buf/dma-buf.c | 65 +--
> 3 files changed, 34 insertions(+), 42 deletions(-)
>
>diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-
>buf-sysfs-stats.c
>index 2bba0babcb62..4b680e10c15a 100644
>--- a/drivers/dma-buf/dma-buf-sysfs-stats.c
>+++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
>@@ -168,14 +168,11 @@ void dma_buf_uninit_sysfs_statistics(void)
> kset_unregister(dma_buf_stats_kset);
> }
>
>-int dma_buf_stats_setup(struct dma_buf *dmabuf)
>+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file)
> {
> struct dma_buf_sysfs_entry *sysfs_entry;
> int ret;
>
>- if (!dmabuf || !dmabuf->file)
>- return -EINVAL;
>-
> if (!dmabuf->exp_name) {
> pr_err("exporter name must not be empty if stats
>needed\n");
> return -EINVAL;
>@@ -192,7 +189,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf)
>
> /* create the directory for buffer stats */
> ret = kobject_init_and_add(_entry->kobj, _buf_ktype,
>NULL,
>- "%lu", file_inode(dmabuf->file)->i_ino);
>+ "%lu", file_inode(file)->i_ino);
> if (ret)
> goto err_sysfs_dmabuf;
>
>diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-
>buf-sysfs-stats.h
>index a49c6e2650cc..7a8a995b75ba 100644
>--- a/drivers/dma-buf/dma-buf-sysfs-stats.h
>+++ b/drivers/dma-buf/dma-buf-sysfs-stats.h
>@@ -13,7 +13,7 @@
> int dma_buf_init_sysfs_statistics(void);
> void dma_buf_uninit_sysfs_statistics(void);
>
>-int dma_buf_stats_setup(struct dma_buf *dmabuf);
>+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file);
>
> void dma_buf_stats_teardown(struct dma_buf *dmabuf);
> #else
>@@ -25,7 +25,7 @@ static inline int dma_buf_init_sysfs_statistics(void)
>
> static inline void dma_buf_uninit_sysfs_statistics(void) {}
>
>-static inline int dma_buf_stats_setup(struct dma_buf *dmabuf)
>+static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file
>*file)
> {
> return 0;
> }
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index e6f36c014c4c..ea08049b70ae 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -614,19 +614,11 @@ struct dma_buf *dma_buf_export(const struct
>dma_buf_export_info *exp_info)
> size_t alloc_size = sizeof(struct dma_buf);
> int ret;
>
>- if (!exp_info->resv)
>- alloc_size += sizeof(struct dma_resv);
>- else
>- /* prevent _buf[1] == dma_buf->resv */
>- alloc_size += 1;
>-
>- if (WARN_ON(!exp_info->priv
>-|| !exp_info->ops
>-|| !exp_info->ops->map_dma_buf
>-|| !exp_info->ops->unmap_dma_buf
>-|| !exp_info->ops->release)) {
>+ if (WARN_ON(!exp_info->priv || !exp_info->ops
>+ || !exp_info->ops->map_dma_buf
>+ || !exp_info->ops->unmap_dma_buf
>+ || !exp_info->ops->release))
> return ERR_PTR(-EINVAL);
>- }
>
> if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> (exp_info->ops->pin || exp_info->ops->unpin)))
>@@ -638,10 +630,21 @@ struct dma_buf *dma_buf_export(const struct
>dma_buf_export_info *exp_info)
> if (!try_module_get(exp_info->owner))
> return ERR_PTR(-ENOENT);
>
>+ file = dma_buf_getfile(exp_info->size, exp_info->flags);
Hi Christian,
dma_buf_getfile takes a dmabuf, here you have a size?
Did you change this function somewhere?
with that addressed
This cleanup makes sense to me.
Reviewed-by: Michael J. Ruhl
M
>+ if
RE: [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>-Original Message-
>From: dri-devel On Behalf Of
>Andy Shevchenko
>Sent: Monday, November 14, 2022 11:22 AM
>To: Jakob Koschel ; Andy Shevchenko
>; Greg Kroah-Hartman
>; Mathias Nyman
>; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux-
>u...@vger.kernel.org
>Cc: Tvrtko Ursulin ; Kevin Cernekee
>; Nyman, Mathias ; Vivi,
>Rodrigo ; Andrew Morton foundation.org>
>Subject: [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>
>Some of the existing users, and definitely will be new ones, want to
>count existing nodes in the list. Provide a generic API for that by
>moving code from i915 to list.h.
>
>Signed-off-by: Andy Shevchenko
>---
>v2: dropped the duplicate code in i915 (LKP)
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
> include/linux/list.h | 13 +
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>index 6ae8b07cfaa1..b5d474be564d 100644
>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>@@ -2085,17 +2085,6 @@ static void print_request_ring(struct drm_printer
>*m, struct i915_request *rq)
> }
> }
>
>-static unsigned long list_count(struct list_head *list)
>-{
>- struct list_head *pos;
>- unsigned long count = 0;
>-
>- list_for_each(pos, list)
>- count++;
>-
>- return count;
>-}
>-
> static unsigned long read_ul(void *p, size_t x)
> {
> return *(unsigned long *)(p + x);
>@@ -2270,7 +2259,7 @@ void intel_engine_dump(struct intel_engine_cs
>*engine,
> spin_lock_irqsave(>sched_engine->lock, flags);
> engine_dump_active_requests(engine, m);
>
>- drm_printf(m, "\tOn hold?: %lu\n",
>+ drm_printf(m, "\tOn hold?: %zu\n",
> list_count(>sched_engine->hold));
> spin_unlock_irqrestore(>sched_engine->lock, flags);
>
>diff --git a/include/linux/list.h b/include/linux/list.h
>index 61762054b4be..098eccf8c1b6 100644
>--- a/include/linux/list.h
>+++ b/include/linux/list.h
>@@ -655,6 +655,19 @@ static inline void list_splice_tail_init(struct list_head
>*list,
>!list_is_head(pos, (head)); \
>pos = n, n = pos->prev)
>
>+/**
>+ * list_count - count nodes in the list
>+ * @head: the head for your list.
>+ */
>+#define list_count(head) \
>+({\
>+ struct list_head *__tmp;\
>+ size_t __i = 0; \
>+ list_for_each(__tmp, head) \
>+ __i++; \
>+ __i;\
>+})
So all of the non-list_for_each code appears to be an inline.
This which, resembles the non-list_for_each pattern is a macro?
Just curious as to why the macro rather than inline?
Mike
+
> /**
> * list_entry_is_head - test if the entry points to the head of the list
> * @pos: the type * to cursor
>--
>2.35.1
RE: [PATCH v2 06/16] igb: Proactively round up to kmalloc bucket size
>-Original Message-
>From: Kees Cook
>Sent: Friday, September 23, 2022 4:28 PM
>To: Vlastimil Babka
>Cc: Kees Cook ; Brandeburg, Jesse
>; Nguyen, Anthony L
>; David S. Miller ;
>Eric Dumazet ; Jakub Kicinski ;
>Paolo Abeni ; intel-wired-...@lists.osuosl.org;
>net...@vger.kernel.org; Ruhl, Michael J ;
>Hyeonggon Yoo <42.hye...@gmail.com>; Christoph Lameter
>; Pekka Enberg ; David Rientjes
>; Joonsoo Kim ; Andrew
>Morton ; Greg Kroah-Hartman
>; Nick Desaulniers
>; Alex Elder ; Josef Bacik
>; David Sterba ; Sumit Semwal
>; Christian König ;
>Daniel Micay ; Yonghong Song ;
>Marco Elver ; Miguel Ojeda ; linux-
>ker...@vger.kernel.org; linux...@kvack.org; linux-bt...@vger.kernel.org;
>linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.org; linaro-mm-
>s...@lists.linaro.org; linux-fsde...@vger.kernel.org; d...@openvswitch.org;
>x...@kernel.org; l...@lists.linux.dev; linux-harden...@vger.kernel.org
>Subject: [PATCH v2 06/16] igb: Proactively round up to kmalloc bucket size
>
>In preparation for removing the "silently change allocation size"
>users of ksize(), explicitly round up all q_vector allocations so that
>allocations can be correctly compared to ksize().
>
>Additionally fix potential use-after-free in the case of new allocation
>failure: only free memory if the replacement allocation succeeds.
>
>Cc: Jesse Brandeburg
>Cc: Tony Nguyen
>Cc: "David S. Miller"
>Cc: Eric Dumazet
>Cc: Jakub Kicinski
>Cc: Paolo Abeni
>Cc: intel-wired-...@lists.osuosl.org
>Cc: net...@vger.kernel.org
>Signed-off-by: Kees Cook
>---
> drivers/net/ethernet/intel/igb/igb_main.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
>b/drivers/net/ethernet/intel/igb/igb_main.c
>index 2796e81d2726..eb51e531c096 100644
>--- a/drivers/net/ethernet/intel/igb/igb_main.c
>+++ b/drivers/net/ethernet/intel/igb/igb_main.c
>@@ -1195,15 +1195,16 @@ static int igb_alloc_q_vector(struct igb_adapter
>*adapter,
> return -ENOMEM;
>
> ring_count = txr_count + rxr_count;
>- size = struct_size(q_vector, ring, ring_count);
>+ size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count));
This looks good to me...
> /* allocate q_vector and rings */
> q_vector = adapter->q_vector[v_idx];
> if (!q_vector) {
> q_vector = kzalloc(size, GFP_KERNEL);
> } else if (size > ksize(q_vector)) {
>- kfree_rcu(q_vector, rcu);
> q_vector = kzalloc(size, GFP_KERNEL);
>+ if (q_vector)
>+ kfree_rcu(q_vector, rcu);
Even though this is in the ksize part, this seems like an unrelated change?
Should this be in a different patch?
Also, the kfree_rcu will free q_vector after the RCU grace period?
Is that what you want to do?
How does rcu distinguish between the original q_vector, and the newly kzalloced
one?
Thanks,
Mike
> } else {
> memset(q_vector, 0, size);
> }
>--
>2.34.1
RE: [PATCH 2/5] drm/simpledrm: Use drm_atomic_get_new_plane_state()
>-Original Message-
>From: Thomas Zimmermann
>Sent: Friday, September 23, 2022 3:53 AM
>To: Ruhl, Michael J ; javi...@redhat.com;
>airl...@linux.ie; dan...@ffwll.ch
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 2/5] drm/simpledrm: Use
>drm_atomic_get_new_plane_state()
>
>Hi
>
>Am 22.09.22 um 18:12 schrieb Ruhl, Michael J:
>>> -Original Message-
>>> From: dri-devel On Behalf Of
>>> Thomas Zimmermann
>>> Sent: Thursday, September 22, 2022 9:10 AM
>>> To: javi...@redhat.com; airl...@linux.ie; dan...@ffwll.ch
>>> Cc: Thomas Zimmermann ; dri-
>>> de...@lists.freedesktop.org
>>> Subject: [PATCH 2/5] drm/simpledrm: Use
>>> drm_atomic_get_new_plane_state()
>>>
>>> Lookup the plane's state in atomic_update with the helper
>>> drm_atomic_get_new_plane_state(). Also rename the helpers'
>>> state arguments. No functional changes.
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> ---
>>> drivers/gpu/drm/tiny/simpledrm.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tiny/simpledrm.c
>>> b/drivers/gpu/drm/tiny/simpledrm.c
>>> index 51d01e34d5eb..14782a50f816 100644
>>> --- a/drivers/gpu/drm/tiny/simpledrm.c
>>> +++ b/drivers/gpu/drm/tiny/simpledrm.c
>>> @@ -470,10 +470,10 @@ static const uint64_t
>>> simpledrm_primary_plane_format_modifiers[] = {
>>> };
>>>
>>> static void simpledrm_primary_plane_helper_atomic_update(struct
>>> drm_plane *plane,
>>> -struct
>>> drm_atomic_state *old_state)
>>> +struct
>>> drm_atomic_state *state)
>>> {
>>> - struct drm_plane_state *plane_state = plane->state;
>>> - struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(old_state, plane);
>>> + struct drm_plane_state *plane_state =
>drm_atomic_get_new_plane_state(state, plane);
>>
>> Going from plane->state to drm_atomic_get_new_plane_state seems like a
>slight function change.
>>
>> If this is the equivalent and the "right" way to do this, should the ->state
>part of the data
>> structure be pruned?
>
>The plane->state field is still relevant. I recently learned that the
>state-lookup helpers are supposed to be used in all atomic_check/commit
>functions. Ville gave a description here:
>
> https://lore.kernel.org/dri-devel/yx9pij4lmfhrq...@intel.com/
>
>>
>> The comment for drm_atomic_get_new_plane_state also says that it can
>return NULL.
>>
>> would plane->state be NULL in this case?
>
>I don't think so. In atomic_update, we know that we're supposed to
>change the plane. That requires the state. Maybe it's different in the
>plane's atomic_disable helper, we don't access the state there.
Ok, that makes sense.
If you need it:
Reviewed-by: Michael J. Ruhl
M
>Best regards
>Thomas
>
>>
>> Thanks,
>>
>> M
>>
>>> + struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(state, plane);
>>> struct drm_shadow_plane_state *shadow_plane_state =
>to_drm_shadow_plane_state(plane_state);
>>> struct drm_framebuffer *fb = plane_state->fb;
>>> struct drm_device *dev = plane->dev;
>>> @@ -503,7 +503,7 @@ static void
>>> simpledrm_primary_plane_helper_atomic_update(struct drm_plane
>*plane
>>> }
>>>
>>> static void simpledrm_primary_plane_helper_atomic_disable(struct
>>> drm_plane *plane,
>>> - struct
>>> drm_atomic_state *old_state)
>>> + struct
>>> drm_atomic_state *state)
>>> {
>>> struct drm_device *dev = plane->dev;
>>> struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
>>> --
>>> 2.37.3
>>
>
>--
>Thomas Zimmermann
>Graphics Driver Developer
>SUSE Software Solutions Germany GmbH
>Maxfeldstr. 5, 90409 Nürnberg, Germany
>(HRB 36809, AG Nürnberg)
>Geschäftsführer: Ivo Totev
RE: [PATCH 2/5] drm/simpledrm: Use drm_atomic_get_new_plane_state()
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, September 22, 2022 9:10 AM
>To: javi...@redhat.com; airl...@linux.ie; dan...@ffwll.ch
>Cc: Thomas Zimmermann ; dri-
>de...@lists.freedesktop.org
>Subject: [PATCH 2/5] drm/simpledrm: Use
>drm_atomic_get_new_plane_state()
>
>Lookup the plane's state in atomic_update with the helper
>drm_atomic_get_new_plane_state(). Also rename the helpers'
>state arguments. No functional changes.
>
>Signed-off-by: Thomas Zimmermann
>---
> drivers/gpu/drm/tiny/simpledrm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/tiny/simpledrm.c
>b/drivers/gpu/drm/tiny/simpledrm.c
>index 51d01e34d5eb..14782a50f816 100644
>--- a/drivers/gpu/drm/tiny/simpledrm.c
>+++ b/drivers/gpu/drm/tiny/simpledrm.c
>@@ -470,10 +470,10 @@ static const uint64_t
>simpledrm_primary_plane_format_modifiers[] = {
> };
>
> static void simpledrm_primary_plane_helper_atomic_update(struct
>drm_plane *plane,
>- struct
>drm_atomic_state *old_state)
>+ struct
>drm_atomic_state *state)
> {
>- struct drm_plane_state *plane_state = plane->state;
>- struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(old_state, plane);
>+ struct drm_plane_state *plane_state =
>drm_atomic_get_new_plane_state(state, plane);
Going from plane->state to drm_atomic_get_new_plane_state seems like a slight
function change.
If this is the equivalent and the "right" way to do this, should the ->state
part of the data
structure be pruned?
The comment for drm_atomic_get_new_plane_state also says that it can return
NULL.
would plane->state be NULL in this case?
Thanks,
M
>+ struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(state, plane);
> struct drm_shadow_plane_state *shadow_plane_state =
> to_drm_shadow_plane_state(plane_state);
> struct drm_framebuffer *fb = plane_state->fb;
> struct drm_device *dev = plane->dev;
>@@ -503,7 +503,7 @@ static void
>simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
> }
>
> static void simpledrm_primary_plane_helper_atomic_disable(struct
>drm_plane *plane,
>-struct
>drm_atomic_state *old_state)
>+struct
>drm_atomic_state *state)
> {
> struct drm_device *dev = plane->dev;
> struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
>--
>2.37.3
RE: [PATCH 07/12] igb: Proactively round up to kmalloc bucket size
>-Original Message- >From: dri-devel On Behalf Of >Kees Cook >Sent: Wednesday, September 21, 2022 11:10 PM >To: Vlastimil Babka >Cc: linux-wirel...@vger.kernel.org; Jacob Shin ; >l...@lists.linux.dev; dri-devel@lists.freedesktop.org; linux...@kvack.org; >Eric Dumazet ; Nguyen, Anthony L >; linux-harden...@vger.kernel.org; Sumit >Semwal ; d...@openvswitch.org; x...@kernel.org; >Brandeburg, Jesse ; intel-wired- >l...@lists.osuosl.org; David Rientjes ; Miguel Ojeda >; Yonghong Song ; Paolo Abeni >; linux-me...@vger.kernel.org; Marco Elver >; Kees Cook ; Josef Bacik >; linaro-mm-...@lists.linaro.org; Jakub Kicinski >; David Sterba ; Joonsoo Kim >; Alex Elder ; Greg Kroah- >Hartman ; Nick Desaulniers >; linux-ker...@vger.kernel.org; David S. Miller >; Pekka Enberg ; Daniel >Micay ; net...@vger.kernel.org; linux- >fsde...@vger.kernel.org; Andrew Morton ; >Christian König ; linux-bt...@vger.kernel.org >Subject: [PATCH 07/12] igb: Proactively round up to kmalloc bucket size > >Instead of having a mismatch between the requested allocation size and >the actual kmalloc bucket size, which is examined later via ksize(), >round up proactively so the allocation is explicitly made for the full >size, allowing the compiler to correctly reason about the resulting size >of the buffer through the existing __alloc_size() hint. > >Cc: Jesse Brandeburg >Cc: Tony Nguyen >Cc: "David S. Miller" >Cc: Eric Dumazet >Cc: Jakub Kicinski >Cc: Paolo Abeni >Cc: intel-wired-...@lists.osuosl.org >Cc: net...@vger.kernel.org >Signed-off-by: Kees Cook >--- > drivers/net/ethernet/intel/igb/igb_main.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/net/ethernet/intel/igb/igb_main.c >b/drivers/net/ethernet/intel/igb/igb_main.c >index 2796e81d2726..4d70ee5b0f79 100644 >--- a/drivers/net/ethernet/intel/igb/igb_main.c >+++ b/drivers/net/ethernet/intel/igb/igb_main.c >@@ -1196,6 +1196,7 @@ static int igb_alloc_q_vector(struct igb_adapter >*adapter, > > ring_count = txr_count + rxr_count; > size = struct_size(q_vector, ring, ring_count); >+ size = kmalloc_size_roundup(size); why not: size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); ? m > /* allocate q_vector and rings */ > q_vector = adapter->q_vector[v_idx]; >-- >2.34.1
RE: [PATCH v5 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message-
>From: Dmitry Osipenko
>Sent: Tuesday, September 13, 2022 3:28 PM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner ; Ruhl, Michael J
>
>Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-...@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v5 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Acked-by: Christian König
>Signed-off-by: Dmitry Osipenko
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 14 ++
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
> 3 files changed, 23 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> void *vaddr;
>
>- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 85482a04d158..7cab89618bad 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -290,7 +290,21 @@ void __i915_gem_object_pages_fini(struct
>drm_i915_gem_object *obj)
> __i915_gem_object_free_mmaps(obj);
>
> atomic_set(>mm.pages_pin_count, 0);
>+
>+ /*
>+ * dma_buf_unmap_attachment() requires reservation to be
>+ * locked. The imported GEM shouldn't share reservation lock
>+ * and ttm_bo_cleanup_memtype_use() shouldn't be invoked for
>+ * dma-buf, so it's safe to take the lock.
>+ */
>+ if (obj->base.import_attach)
>+ i915_gem_object_lock(obj, NULL);
>+
> __i915_gem_object_put_pages(obj);
>+
>+ if (obj->base.import_attach)
>+ i915_gem_object_unlock(obj);
>+
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
> }
Hi Dmitry,
I think that this looks correct and reasonable.
Reviewed-by: Michael J. Ruhl
m
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 51ed824b020c..f2f3cfad807b 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> goto out_import;
> }
>
>- st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+ st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
> if (IS_ERR(st)) {
> err = PTR_ERR(st);
> goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> timeout = -ETIME;
> }
> err = timeout > 0 ? 0 : timeout;
>- dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+ dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
> dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
> goto out_obj
RE: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, September 6, 2022 1:09 PM
>To: Ruhl, Michael J
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Sripada,
>Radhakrishna
>Subject: Re: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into mmio_debug_{suspend, resume}
>
>On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
>> >-Original Message-
>> >From: dri-devel On Behalf Of
>> >Matt Roper
>> >Sent: Friday, September 2, 2022 7:33 PM
>> >To: intel-...@lists.freedesktop.org
>> >Cc: dri-devel@lists.freedesktop.org; Sripada, Radhakrishna
>> >
>> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into
>> >mmio_debug_{suspend, resume}
>> >
>> >Moving the locking for MMIO debug (and the final check for unclaimed
>> >accesses when resuming debug after a userspace-initiated forcewake) will
>> >make it simpler to completely skip MMIO debug handling on uncores that
>> >don't support it in future patches.
>> >
>> >Signed-off-by: Matt Roper
>> >Reviewed-by: Radhakrishna Sripada
>> >---
>> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
>> > 1 file changed, 21 insertions(+), 20 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> >b/drivers/gpu/drm/i915/intel_uncore.c
>> >index 9b81b2543ce2..e717ea55484a 100644
>> >--- a/drivers/gpu/drm/i915/intel_uncore.c
>> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
>> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>> >intel_uncore_mmio_debug *mmio_debug)
>> >mmio_debug->unclaimed_mmio_check = 1;
>> > }
>> >
>> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
>>
>> /bike-shedding...
>>
>> It seems like there has been a tend to name functions with the
>>
>> _unlocked
>>
>> postfix when the lock is being taken within the function.
>>
>> Would this be a reasonable name update for these changes?
>
>I think foo_unlocked() naming is usually used when there's also a
>separate foo() that can be called if/when locks are already held (or
>sometimes it's foo() and foo_locked() if the situation is the other way
>around). In this case we still only have one version of the function,
>and it's only called from a single place in the code
>(intel_uncore_forcewake_user_get) so I don't think the special naming is
>necessary. It might actually add confusion here since there's a
>different lock (the general uncore lock) that is still held by the
>caller. It's just the mmio_debug-specific lock that's been moved into
>the mmio-debug specific function here.
Got it. That makes sense.
Thanks,
Mike
>
>Matt
>
>>
>> M
>>
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >
>> >/* Save and disable mmio debugging for the user bypass */
>> >- if (!mmio_debug->suspend_count++) {
>> >- mmio_debug->saved_mmio_check = mmio_debug-
>> >>unclaimed_mmio_check;
>> >- mmio_debug->unclaimed_mmio_check = 0;
>> >+ if (!uncore->debug->suspend_count++) {
>> >+ uncore->debug->saved_mmio_check = uncore->debug-
>> >>unclaimed_mmio_check;
>> >+ uncore->debug->unclaimed_mmio_check = 0;
>> >}
>> >+
>> >+ spin_unlock(>debug->lock);
>> > }
>> >
>> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>> >+
>> >+static void mmio_debug_resume(struct intel_uncore *uncore)
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >+
>> >+ if (!--uncore->debug->suspend_count)
>> >+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>> >>saved_mmio_check;
>> >
>> >- if (!--mmio_debug->suspend_count)
>> >- mmio_debug->unclaimed_mmio_check = mmio_debug-
>> >>saved_mmio_check;
>> >+ if (check_for_unclaimed_mmio(uncore))
>> >+ drm_info(>i915->drm,
>> >+"Invalid mmio detected during user access\n");
>> >+
>&
RE: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: dri-devel On Behalf Of
>Matt Roper
>Sent: Friday, September 2, 2022 7:33 PM
>To: intel-...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org; Sripada, Radhakrishna
>
>Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
>mmio_debug_{suspend, resume}
>
>Moving the locking for MMIO debug (and the final check for unclaimed
>accesses when resuming debug after a userspace-initiated forcewake) will
>make it simpler to completely skip MMIO debug handling on uncores that
>don't support it in future patches.
>
>Signed-off-by: Matt Roper
>Reviewed-by: Radhakrishna Sripada
>---
> drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>b/drivers/gpu/drm/i915/intel_uncore.c
>index 9b81b2543ce2..e717ea55484a 100644
>--- a/drivers/gpu/drm/i915/intel_uncore.c
>+++ b/drivers/gpu/drm/i915/intel_uncore.c
>@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>intel_uncore_mmio_debug *mmio_debug)
> mmio_debug->unclaimed_mmio_check = 1;
> }
>
>-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static void mmio_debug_suspend(struct intel_uncore *uncore)
/bike-shedding...
It seems like there has been a tend to name functions with the
_unlocked
postfix when the lock is being taken within the function.
Would this be a reasonable name update for these changes?
M
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>
> /* Save and disable mmio debugging for the user bypass */
>- if (!mmio_debug->suspend_count++) {
>- mmio_debug->saved_mmio_check = mmio_debug-
>>unclaimed_mmio_check;
>- mmio_debug->unclaimed_mmio_check = 0;
>+ if (!uncore->debug->suspend_count++) {
>+ uncore->debug->saved_mmio_check = uncore->debug-
>>unclaimed_mmio_check;
>+ uncore->debug->unclaimed_mmio_check = 0;
> }
>+
>+ spin_unlock(>debug->lock);
> }
>
>-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>+
>+static void mmio_debug_resume(struct intel_uncore *uncore)
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>+
>+ if (!--uncore->debug->suspend_count)
>+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>>saved_mmio_check;
>
>- if (!--mmio_debug->suspend_count)
>- mmio_debug->unclaimed_mmio_check = mmio_debug-
>>saved_mmio_check;
>+ if (check_for_unclaimed_mmio(uncore))
>+ drm_info(>i915->drm,
>+ "Invalid mmio detected during user access\n");
>+
>+ spin_unlock(>debug->lock);
> }
>
> static const char * const forcewake_domain_names[] = {
>@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
>intel_uncore *uncore)
> spin_lock_irq(>lock);
> if (!uncore->user_forcewake_count++) {
> intel_uncore_forcewake_get__locked(uncore,
>FORCEWAKE_ALL);
>- spin_lock(>debug->lock);
>- mmio_debug_suspend(uncore->debug);
>- spin_unlock(>debug->lock);
>+ mmio_debug_suspend(uncore);
> }
> spin_unlock_irq(>lock);
> }
>@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
>intel_uncore *uncore)
> {
> spin_lock_irq(>lock);
> if (!--uncore->user_forcewake_count) {
>- spin_lock(>debug->lock);
>- mmio_debug_resume(uncore->debug);
>-
>- if (check_for_unclaimed_mmio(uncore))
>- drm_info(>i915->drm,
>- "Invalid mmio detected during user
>access\n");
>- spin_unlock(>debug->lock);
>-
>+ mmio_debug_resume(uncore);
> intel_uncore_forcewake_put__locked(uncore,
>FORCEWAKE_ALL);
> }
> spin_unlock_irq(>lock);
>--
>2.37.2
RE: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message- >From: Dmitry Osipenko >Sent: Friday, September 2, 2022 6:39 AM >To: Ruhl, Michael J ; Dmitry Osipenko >; Jani Nikula ; >Joonas Lahtinen ; Vivi, Rodrigo >; Tvrtko Ursulin ; >Thomas Hellström ; Christian König >; Chris Wilson >Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux- >me...@vger.kernel.org; linaro-mm-...@lists.linaro.org; amd- >g...@lists.freedesktop.org; intel-...@lists.freedesktop.org; >ker...@collabora.com; virtualizat...@lists.linux-foundation.org; linux- >r...@vger.kernel.org; linux-arm-...@vger.kernel.org; David Airlie >; Gerd Hoffmann ; Gurchetan Singh >; Chia-I Wu ; Daniel >Vetter ; Daniel Almeida ; >Gert Wollny ; Gustavo Padovan >; Daniel Stone ; >Tomeu Vizoso ; Maarten Lankhorst >; Maxime Ripard >; Thomas Zimmermann ; >Rob Clark ; Sumit Semwal >; Pan, Xinhui ; Thierry >Reding ; Tomasz Figa ; >Marek Szyprowski ; Mauro Carvalho Chehab >; Alex Deucher ; >Qiang Yu ; Srinivas Kandagatla >; Amol Maheshwari >; Jason Gunthorpe ; Leon >Romanovsky ; Gross, Jurgen ; Stefano >Stabellini ; Oleksandr Tyshchenko >; Tomi Valkeinen ; >Russell King ; Lucas Stach ; >Christian Gmeiner >Subject: Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking >specification > >02.09.2022 13:31, Dmitry Osipenko пишет: >> 01.09.2022 17:02, Ruhl, Michael J пишет: >> ... >>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >>>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >>>> drm_i915_private *i915, >>>>continue; >>>>} >>>> >>>> + /* >>>> + * dma_buf_unmap_attachment() requires reservation to be >>>> + * locked. The imported GEM shouldn't share reservation lock, >>>> + * so it's safe to take the lock. >>>> + */ >>>> + if (obj->base.import_attach) >>>> + i915_gem_object_lock(obj, NULL); >>> >>> There is a lot of stuff going here. Taking the lock may be premature... >>> >>>>__i915_gem_object_pages_fini(obj); >>> >>> The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where >>> unmap_attachment is actually called, would it make more sense to make >>> do the locking there? >> >> The __i915_gem_object_put_pages() is invoked with a held reservation >> lock, while freeing object is a special time when we know that GEM is >> unused. >> >> The __i915_gem_free_objects() was taking the lock two weeks ago until >> the change made Chris Wilson [1] reached linux-next. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- >next.git/commit/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c >> >> I don't think we can take the lock within >> i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code >paths. > >On the other hand, we can check whether the GEM's refcount number is >zero in i915_gem_object_put_pages_dmabuf() and then take the lock if >it's zero. > >Also, seems it should be possible just to bail out from >i915_gem_object_put_pages_dmabuf() if refcount=0. The further >drm_prime_gem_destroy() will take care of unmapping. Perhaps this could >be the best option, I'll give it a test. i915_gem_object_put_pages() is uses the SG, and the usage for drm_prim_gem_destroy() from __i915_gem_free_objects() doesn't use the SG because it has been "freed" already, I am not sure if that would work... Hmm.. with that in mind, maybe moving the base.import_attach check to __i915_gem_object_put_pages with your attach check? atomic_set(>mm.pages_pin_count, 0); if (obj->base.import) i915_gem_object_lock(obj, NULL); __i915_gem_object_put_pages(obj); if (obj->base.import) i915_gem_object_unlock(obj, NULL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); Pretty much one step up from the dmabuf interface, but we are guaranteed to not have any pinned pages? The other caller of __i915_gem_object_pages_fini is the i915_ttm move_notify which should not conflict (export side, not import side). Since it appears that not locking during the clean up is desirable, trying to make sure take the lock is taken at the last moment might be the right path? M
RE: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message-
>From: Dmitry Osipenko
>Sent: Wednesday, August 31, 2022 11:38 AM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner
>Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-...@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Signed-off-by: Dmitry Osipenko
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> void *vaddr;
>
>- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 389e9f157ca5..7e2a9b02526c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>drm_i915_private *i915,
> continue;
> }
>
>+ /*
>+ * dma_buf_unmap_attachment() requires reservation to be
>+ * locked. The imported GEM shouldn't share reservation lock,
>+ * so it's safe to take the lock.
>+ */
>+ if (obj->base.import_attach)
>+ i915_gem_object_lock(obj, NULL);
There is a lot of stuff going here. Taking the lock may be premature...
> __i915_gem_object_pages_fini(obj);
The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where
unmap_attachment is actually called, would it make more sense to make
do the locking there?
Mike
>+
>+ if (obj->base.import_attach)
>+ i915_gem_object_unlock(obj);
>+
> __i915_gem_free_object(obj);
>
> /* But keep the pointer alive for RCU-protected lookups */
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 62c61af77a42..9e3ed634aa0e 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> goto out_import;
> }
>
>- st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+ st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
> if (IS_ERR(st)) {
> err = PTR_ERR(st);
> goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> timeout = -ETIME;
> }
> err = timeout > 0 ? 0 : timeout;
>- dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+ dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
> dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
> goto out_obj;
> }
>
>- err = dma_buf_vmap(dmabuf, );
>+ err = dma_buf_vmap_unlocked(dmabuf, );
> dma_map = err ? NULL : map.vaddr;
> if (!dma_map) {
> pr_err("dma_buf_vmap failed\n");
>@@ -337,7 +337,7 @@ static int
RE: [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined gutting
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined
>gutting
>
>That should not be necessary any more when drivers should at least be
>able to handle a move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1530982338e9..1e76149c62ff 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -603,16 +603,10 @@ EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
> */
> int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> struct ttm_buffer_object *ghost;
>- struct ttm_resource *sys_res;
> struct ttm_tt *ttm;
> int ret;
>
>- ret = ttm_resource_alloc(bo, _mem, _res);
>- if (ret)
>- return ret;
>-
> /* If already idle, no need for ghost object dance. */
> ret = ttm_bo_wait(bo, false, true);
> if (ret != -EBUSY) {
>@@ -620,14 +614,13 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> /* See comment below about clearing. */
> ret = ttm_tt_create(bo, true);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
> } else {
> ttm_tt_unpopulate(bo->bdev, bo->ttm);
> if (bo->type == ttm_bo_type_device)
> ttm_tt_mark_for_clear(bo->ttm);
> }
> ttm_resource_free(bo, >resource);
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
> }
>
>@@ -644,7 +637,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object
>*bo)
> ret = ttm_tt_create(bo, true);
> swap(bo->ttm, ttm);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
>
> ret = ttm_buffer_object_transfer(bo, );
> if (ret)
>@@ -658,13 +651,9 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> dma_resv_unlock(>base._resv);
> ttm_bo_put(ghost);
> bo->ttm = ttm;
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
>
> error_destroy_tt:
> ttm_tt_destroy(bo->bdev, ttm);
>-
>-error_free_sys_mem:
>- ttm_resource_free(bo, _res);
> return ret;
> }
>--
>2.25.1
RE: [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO creation
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO
>creation
>
>That should not be necessary any more when drivers should at least be
>able to handle the move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
> 1 file changed, 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index a2f49bdda8a1..f491be751a2f 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -960,7 +960,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
>struct sg_table *sg, struct dma_resv *resv,
>void (*destroy) (struct ttm_buffer_object *))
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> int ret;
>
> kref_init(>kref);
>@@ -978,12 +977,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
> bo->base.resv = >base._resv;
> atomic_inc(_glob.bo_count);
>
>- ret = ttm_resource_alloc(bo, _mem, >resource);
>- if (unlikely(ret)) {
>- ttm_bo_put(bo);
>- return ret;
>- }
>-
> /*
>* For ttm_bo_type_device buffers, allocate
>* address space from the device.
>--
>2.25.1
RE: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>
>Allow BOs to exist without backing store.
>
>v2: handle ttm_bo_move_memcpy as well.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +--
> 2 files changed, 13 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 984535d6a2d0..a2f49bdda8a1 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -904,7 +904,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1cbfb00c1d65..1530982338e9 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -137,8 +137,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> ttm_manager_type(bo->bdev, dst_mem->mem_type);
> struct ttm_tt *ttm = bo->ttm;
> struct ttm_resource *src_mem = bo->resource;
>- struct ttm_resource_manager *src_man =
>- ttm_manager_type(bdev, src_mem->mem_type);
>+ struct ttm_resource_manager *src_man;
> union {
> struct ttm_kmap_iter_tt tt;
> struct ttm_kmap_iter_linear_io io;
>@@ -147,6 +146,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> bool clear;
> int ret = 0;
>
>+ if (!src_mem)
>+ return 0;
>+
>+ src_man = ttm_manager_type(bdev, src_mem->mem_type);
> if (ttm && ((ttm->page_flags & TTM_TT_FLAG_SWAPPED) ||
> dst_man->use_tt)) {
> ret = ttm_tt_populate(bdev, ttm, ctx);
>--
>2.25.1
RE: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 92cd19021084..f83fb43b2e44 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1006,7 +1006,8 @@ nouveau_bo_move(struct ttm_buffer_object *bo,
>bool evict,
> }
>
> /* Fake bo copy. */
>- if (old_reg->mem_type == TTM_PL_SYSTEM && !bo->ttm) {
>+ if (!old_reg || (old_reg->mem_type == TTM_PL_SYSTEM &&
>+ !bo->ttm)) {
> ttm_bo_move_null(bo, new_reg);
> goto out;
> }
>--
>2.25.1
RE: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index d9cfe259f2a9..677d1dfab37f 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -1305,7 +1305,7 @@ void amdgpu_bo_release_notify(struct
>ttm_buffer_object *bo)
> if (bo->base.resv == >base._resv)
> amdgpu_amdkfd_remove_fence_on_pt_pd_bos(abo);
>
>- if (bo->resource->mem_type != TTM_PL_VRAM ||
>+ if (!bo->resource || bo->resource->mem_type != TTM_PL_VRAM ||
> !(abo->flags &
>AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE) ||
> adev->in_suspend || adev->shutdown)
> return;
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index be6f76a30ac6..3bddf266e8b5 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -471,7 +471,8 @@ static int amdgpu_bo_move(struct ttm_buffer_object
>*bo, bool evict,
>
> adev = amdgpu_ttm_adev(bo->bdev);
>
>- if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>+ if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM &&
>+ bo->ttm == NULL)) {
> ttm_bo_move_null(bo, new_mem);
> goto out;
> }
>--
>2.25.1
RE: [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 6 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 147 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 +-
> include/drm/ttm/ttm_bo_api.h | 93 ++---
> 9 files changed, 129 insertions(+), 150 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 2c82b1d5a0d7..d9cfe259f2a9 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -591,7 +591,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = _bo_destroy;
>
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp-
>>type,
>+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, bp->type,
>>placement, page_align, , NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index d607043716d3..125160b534be 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,9 +226,9 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init(bdev, >bo, size, ttm_bo_type_device,
>->placement, pg_align, false, NULL, NULL,
>-ttm_buffer_object_destroy);
>+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
>+ >placement, pg_align, false, NULL,
>NULL,
>+ ttm_buffer_object_destroy);
> if (ret)
> return ERR_PTR(ret);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..70e2ed4e99df 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, _sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ _sys_placement, page_size >>
>PAGE_SHIFT,
> , NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..92cd19021084 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -307,9 +307,9 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
>+ >placement, align >> PAGE_SHIFT,
>false,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..695d9308d1f0 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
> qxl_ttm_placement_from_domain(bo, domain);
>
> bo->tbo.priority = priority;
>- r =
RE: [PATCH] drm/msm/disp/dpu1: remove supoerflous init
>-Original Message-
>From: dri-devel On Behalf Of
>Vinod Koul
>Sent: Tuesday, May 24, 2022 6:36 AM
>To: Dmitry Baryshkov
>Cc: Liu, Yujie ; linux-arm-...@vger.kernel.org; Abhinav
>Kumar ; dri-devel@lists.freedesktop.org; Bjorn
>Andersson ; Vinod Koul ;
>freedr...@lists.freedesktop.org
>Subject: [PATCH] drm/msm/disp/dpu1: remove supoerflous init
s/supoerflous/superfluous/
m
>Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
>encoder") added dsc_common_mode variable which was set to zero but then
>again programmed, so drop the supoerflous init.
>
>Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
>Reported-by: kernel test robot
>Signed-off-by: Vinod Koul
>---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>index 51f24ba68375..388125c8bda1 100644
>--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>@@ -1798,7 +1798,6 @@ static void dpu_encoder_prep_dsc(struct
>dpu_encoder_virt *dpu_enc,
> }
> }
>
>- dsc_common_mode = 0;
> pic_width = dsc->drm->pic_width;
>
> dsc_common_mode = DSC_MODE_MULTIPLEX |
>DSC_MODE_SPLIT_PANEL;
>--
>2.34.1
RE: [PATCH 09/11] drm/ttm: audit bo->resource usage
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 09/11] drm/ttm: audit bo->resource usage
>
>Allow BOs to exist without backing store.
Took me a while to figure out that only the last line is related to this commit
message.
Could you add something like:
Refactor usage information.
Allow BOs to exist without backing store.
?
Would make this patch a little easier to decipher.
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 2b01cb30694a..a55564c8b57c 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -898,7 +898,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>--
>2.25.1
RE: [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 92 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 ++-
> include/drm/ttm/ttm_bo_api.h | 44 +--
> 9 files changed, 75 insertions(+), 88 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 5444515c1476..116c8d31e646 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -590,7 +590,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = _bo_destroy;
>
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp-
>>type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, bp->type,
>>placement, page_align, , NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 7449cbc2f925..73e91baccea0 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,7 +226,7 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init_reserved(bdev, >bo, size,
>ttm_bo_type_device,
>+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
> >placement, pg_align, , NULL,
>NULL,
> ttm_buffer_object_destroy);
> if (ret)
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..253188da91eb 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, _sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_validate(>bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ _sys_placement, page_size >>
>PAGE_SHIFT,
> , NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 858b9382036c..666941804297 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -308,7 +308,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
> >placement, align >> PAGE_SHIFT,
>,
> sg, robj, nouveau_bo_del_ttm);
> if (ret) {
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..da3f76f508ea 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
> qxl_ttm_placement_from_domain(bo, domain);
>
> bo->tbo.priority = priority;
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, type,
>>placement, 0, , NULL, NULL,
>_ttm_bo_destroy);
> if (unlikely(r != 0)) {
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 1d414ff4ab0c..550ca056b3ac 100644
>---
RE: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, May 19, 2022 5:55 AM >To: intel-...@lists.freedesktop.org >Cc: matthew.william.a...@gmail.com; Christian König >; dri-devel@lists.freedesktop.org >Subject: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX > >It's the only driver using this. > >Signed-off-by: Christian König >--- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >index 85a66014c2b6..c4f376d5e1d0 100644 >--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >@@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, > return -ENOMEM; > } > >+ if (!bo_free) >+ bo_free = vmw_bo_default_destroy; >+ vmw_bo_init has a WARN_ON if this is NULL. Also, all of the callers use vmw_bo_bo_free() or vmw_gem_destroy(). Both of those unmap, release and then free the object. It doesn't look like vmw_bo_default_destroy does this work. Is this the right "default" path? Or should the WARN_ON be used to check for this? M > ret = vmw_bo_init(vmw, *p_bo, size, > placement, interruptible, pin, > bo_free); >-- >2.25.1
RE: [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..858b9382036c 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -302,19 +302,23 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64
>size, int align, u32 domain,
> struct sg_table *sg, struct dma_resv *robj)
> {
> int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
>+ struct ttm_operation_ctx ctx = { false, false };
> int ret;
>
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ >placement, align >> PAGE_SHIFT,
>,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
> }
>
>+ if (!robj)
>+ ttm_bo_unreserve(>bo);
>+
Ok, this implies that patch 1 does have an issue.
I see this usage in patch 1, 2, and 3. Would it make sense to move this
_unreserve to ttm_bo_init_reserved?
Mike
> return 0;
> }
>
>--
>2.25.1
RE: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 6c4a6802ca96..1d414ff4ab0c 100644
>--- a/drivers/gpu/drm/radeon/radeon_object.c
>+++ b/drivers/gpu/drm/radeon/radeon_object.c
>@@ -133,9 +133,12 @@ int radeon_bo_create(struct radeon_device *rdev,
>struct dma_resv *resv,
>struct radeon_bo **bo_ptr)
> {
>- struct radeon_bo *bo;
>- enum ttm_bo_type type;
> unsigned long page_align = roundup(byte_align, PAGE_SIZE) >>
>PAGE_SHIFT;
>+
>+ /* Kernel allocation are uninterruptible */
>+ struct ttm_operation_ctx ctx = { !kernel, false };
>+ enum ttm_bo_type type;
>+ struct radeon_bo *bo;
> int r;
>
> size = ALIGN(size, PAGE_SIZE);
>@@ -200,11 +203,13 @@ int radeon_bo_create(struct radeon_device *rdev,
> #endif
>
> radeon_ttm_placement_from_domain(bo, domain);
>- /* Kernel allocation are uninterruptible */
> down_read(>pm.mclk_lock);
>- r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>- >placement, page_align, !kernel, sg, resv,
>- _ttm_bo_destroy);
>+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ >placement, page_align, , sg, resv,
>+ _ttm_bo_destroy);
>+if (!r)
>+ ttm_bo_unreserve(>tbo);
>+
Hi Christian,
I am not understanding this unreserve.
The original code path does not have it. It looks like tt_bo_init will do
this, but only if !resv.
Should this be:
if (!resv)
ttm_bo_unreserve(>tbo);
?
M
> up_read(>pm.mclk_lock);
> if (unlikely(r != 0)) {
> return r;
>--
>2.25.1
RE: [PATCH v3] dma-buf: dma-heap: Add a size check for allocation
>-Original Message- >From: dri-devel On Behalf Of >Ruhl, Michael J >Sent: Thursday, January 13, 2022 7:58 AM >To: guangming@mediatek.com; sumit.sem...@linaro.org >Cc: jianjiao.z...@mediatek.com; lm...@codeaurora.org; >wsd_upstr...@mediatek.com; christian.koe...@amd.com; linux- >ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; >yf.w...@mediatek.com; linaro-mm-...@lists.linaro.org; linux- >media...@lists.infradead.org; libo.k...@mediatek.com; >benjamin.gaign...@linaro.org; bo.s...@mediatek.com; >matthias@gmail.com; labb...@redhat.com; >mingyuan...@mediatek.com; linux-arm-ker...@lists.infradead.org; linux- >me...@vger.kernel.org >Subject: RE: [PATCH v3] dma-buf: dma-heap: Add a size check for allocation > > >>-Original Message- >>From: dri-devel On Behalf Of >>guangming@mediatek.com >>Sent: Thursday, January 13, 2022 7:34 AM >>To: sumit.sem...@linaro.org >>Cc: linux-arm-ker...@lists.infradead.org; mingyuan...@mediatek.com; >>Guangming ; >>wsd_upstr...@mediatek.com; linux-ker...@vger.kernel.org; dri- >>de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; >>yf.w...@mediatek.com; libo.k...@mediatek.com; >>benjamin.gaign...@linaro.org; bo.s...@mediatek.com; >>matthias@gmail.com; linux-media...@lists.infradead.org; >>lm...@codeaurora.org; labb...@redhat.com; christian.koe...@amd.com; >>jianjiao.z...@mediatek.com; linux-me...@vger.kernel.org >>Subject: [PATCH v3] dma-buf: dma-heap: Add a size check for allocation >> >>From: Guangming >> >>Add a size check for allocation since the allocation size is >>always less than the total DRAM size. >> >>Without this check, once the invalid size allocation runs on a process that >>can't be killed by OOM flow(such as "gralloc" on Android devices), it will >>cause a kernel exception, and to make matters worse, we can't find who are >>using >>so many memory with "dma_buf_debug_show" since the relevant dma-buf >>hasn't exported. >> >>To make OOM issue easier, maybe need dma-buf framework to dump the >>buffer size >>under allocating in "dma_buf_debug_show". >> >>Signed-off-by: Guangming >>Signed-off-by: jianjiao zeng >>--- >>v3: 1. update patch, use right shift to replace division. >>2. update patch, add reason in code and commit message. >>v2: 1. update size limitation as total_dram page size. >>2. update commit message >>--- >> drivers/dma-buf/dma-heap.c | 10 ++ >> 1 file changed, 10 insertions(+) >> >>diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >>index 56bf5ad01ad5..1fd382712584 100644 >>--- a/drivers/dma-buf/dma-heap.c >>+++ b/drivers/dma-buf/dma-heap.c >>@@ -55,6 +55,16 @@ static int dma_heap_buffer_alloc(struct dma_heap >>*heap, size_t len, >> struct dma_buf *dmabuf; >> int fd; >> >>+ /* >>+ * Invalid size check. The "len" should be less than totalram. >>+ * >>+ * Without this check, once the invalid size allocation runs on a >>process >>that >>+ * can't be killed by OOM flow(such as "gralloc" on Android devices), it >>will >>+ * cause a kernel exception, and to make matters worse, we can't find >>who are using >>+ * so many memory with "dma_buf_debug_show" since the relevant >>dma-buf hasn't exported. >>+ */ >>+ if (len >> PAGE_SHIFT > totalram_pages()) > >If your "heap" is from cma, is this still a valid check? And thinking a bit further, if I create a heap from something else (say device memory), you will need to be able to figure out the maximum allowable check for the specific heap. Maybe the heap needs a callback for max size? m >M > >>+ return -EINVAL; >> /* >> * Allocations from all heaps have to begin >> * and end on page boundaries. >>-- >>2.17.1
RE: [PATCH v3] dma-buf: dma-heap: Add a size check for allocation
>-Original Message- >From: dri-devel On Behalf Of >guangming@mediatek.com >Sent: Thursday, January 13, 2022 7:34 AM >To: sumit.sem...@linaro.org >Cc: linux-arm-ker...@lists.infradead.org; mingyuan...@mediatek.com; >Guangming ; >wsd_upstr...@mediatek.com; linux-ker...@vger.kernel.org; dri- >de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; >yf.w...@mediatek.com; libo.k...@mediatek.com; >benjamin.gaign...@linaro.org; bo.s...@mediatek.com; >matthias@gmail.com; linux-media...@lists.infradead.org; >lm...@codeaurora.org; labb...@redhat.com; christian.koe...@amd.com; >jianjiao.z...@mediatek.com; linux-me...@vger.kernel.org >Subject: [PATCH v3] dma-buf: dma-heap: Add a size check for allocation > >From: Guangming > >Add a size check for allocation since the allocation size is >always less than the total DRAM size. > >Without this check, once the invalid size allocation runs on a process that >can't be killed by OOM flow(such as "gralloc" on Android devices), it will >cause a kernel exception, and to make matters worse, we can't find who are >using >so many memory with "dma_buf_debug_show" since the relevant dma-buf >hasn't exported. > >To make OOM issue easier, maybe need dma-buf framework to dump the >buffer size >under allocating in "dma_buf_debug_show". > >Signed-off-by: Guangming >Signed-off-by: jianjiao zeng >--- >v3: 1. update patch, use right shift to replace division. >2. update patch, add reason in code and commit message. >v2: 1. update size limitation as total_dram page size. >2. update commit message >--- > drivers/dma-buf/dma-heap.c | 10 ++ > 1 file changed, 10 insertions(+) > >diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >index 56bf5ad01ad5..1fd382712584 100644 >--- a/drivers/dma-buf/dma-heap.c >+++ b/drivers/dma-buf/dma-heap.c >@@ -55,6 +55,16 @@ static int dma_heap_buffer_alloc(struct dma_heap >*heap, size_t len, > struct dma_buf *dmabuf; > int fd; > >+ /* >+ * Invalid size check. The "len" should be less than totalram. >+ * >+ * Without this check, once the invalid size allocation runs on a >process >that >+ * can't be killed by OOM flow(such as "gralloc" on Android devices), it >will >+ * cause a kernel exception, and to make matters worse, we can't find >who are using >+ * so many memory with "dma_buf_debug_show" since the relevant >dma-buf hasn't exported. >+ */ >+ if (len >> PAGE_SHIFT > totalram_pages()) If your "heap" is from cma, is this still a valid check? M >+ return -EINVAL; > /* >* Allocations from all heaps have to begin >* and end on page boundaries. >-- >2.17.1
RE: [PATCH i-g-t 1/1] tests/i915_pxp: Use ioctl_wrapper for DRM_IOCTL_PRIME_HANDLE_TO_FD
>-Original Message-
>From: Teres Alexis, Alan Previn
>Sent: Wednesday, October 6, 2021 12:52 PM
>To: igt-...@lists.freedesktop.org
>Cc: Teres Alexis, Alan Previn ; dri-
>de...@lists.freedesktop.org; Ruhl; Ruhl, Michael J
>; Vivi, Rodrigo
>Subject: [PATCH i-g-t 1/1] tests/i915_pxp: Use ioctl_wrapper for
>DRM_IOCTL_PRIME_HANDLE_TO_FD
>
>Replace private helper with call to ioctl_wrapper for
>DRM_IOCTL_PRIME_HANDLE_TO_FD.
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Alan Previn
>---
> tests/i915/gem_pxp.c | 20 +---
> 1 file changed, 1 insertion(+), 19 deletions(-)
>
>diff --git a/tests/i915/gem_pxp.c b/tests/i915/gem_pxp.c
>index 79040165..0430f4b8 100644
>--- a/tests/i915/gem_pxp.c
>+++ b/tests/i915/gem_pxp.c
>@@ -622,23 +622,6 @@ static void test_render_pxp_protsrc_to_protdest(int
>i915)
> buf_ops_destroy(bops);
> }
>
>-static int export_handle(int fd, uint32_t handle, int *outfd)
>-{
>- struct drm_prime_handle args;
>- int ret;
>-
>- args.handle = handle;
>- args.flags = DRM_CLOEXEC;
>- args.fd = -1;
>-
>- ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
>- if (ret)
>- ret = errno;
>- *outfd = args.fd;
>-
>- return ret;
>-}
>-
> static void test_pxp_dmabuffshare_refcnt(void)
> {
> uint32_t ctx[2], sbo[2], dbo[2];
>@@ -659,8 +642,7 @@ static void test_pxp_dmabuffshare_refcnt(void)
> dbo[0] = alloc_and_fill_dest_buff(fd[0], true,
>TSTSURF_SIZE,
>
>TSTSURF_INITCOLOR1);
> } else {
>- ret = export_handle(fd[0], dbo[0], _fd);
>- igt_assert(ret == 0);
>+ dmabuf_fd = prime_handle_to_fd(fd[0], dbo[0]);
> dbo[1] = prime_fd_to_handle(fd[1], dmabuf_fd);
> igt_assert(dbo[1]);
> }
>--
>2.25.1
RE: [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>-Original Message-
>From: Daniel Vetter
>Sent: Wednesday, June 30, 2021 10:02 AM
>To: Thomas Hellström ; Christian König
>
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Auld,
>Matthew ; maarten.lankho...@linux.intel.com;
>dan...@ffwll.ch; Ruhl, Michael J
>Subject: Re: [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>
>On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
>> If our exported dma-bufs are imported by another instance of our driver,
>> that instance will typically have the imported dma-bufs locked during
>> dma_buf_map_attachment(). But the exporter also locks the same
>reservation
>> object in the map_dma_buf() callback, which leads to recursive locking.
>>
>> Add a live selftest to exercise both dynamic and non-dynamic exports,
>> and as a workaround until we fully support dynamic import and export,
>> declare the exporter dynamic by providing pin() and unpin()
>implementations.
>> For dynamic importers, make sure we keep the pinning also in
>map_dma_buf(),
>> to ensure we never need to call dma_buf_move_notify().
>> Calling dma_buf_move_notify() is at the discretion of the exporter.
>>
>> v2:
>> - Extend the selftest with a fake dynamic importer.
>> - Provide real pin and unpin callbacks to not abuse the interface.
>>
>> Reported-by: Michael J. Ruhl
>> Signed-off-by: Thomas Hellström
>
>I'm not happy with this, because i915 is currently violating the dma-resv
>fencing rules for dynamic dma-buf.
>
>Yes since this is just the exporter we can probably get away with yolo'ing
>things, but Christian and me just spend a lot of angry typing figuring out
>what the rules actually are, so I really don't like bending them even more
>just because it's less typing.
>
>All we need for a quick interim fix is to not take the dma_resv_lock from
>our map/unamp callbacks. Pinning our backing storage from attach/detach
>callbacks (which are also called under dma_resv_lock) would also achieve
>that, without mudding any waters. So essentially just moving the
>pin/unpin_pages_unlocked and we should be good, which is almost as little
>typing.
>
>Michael, since Thomas is on vacations now, care to type that up? The
>selftest is imo solid.
Yes, I will get that done.
Mike
>This is also consistent with what all other ttm based drivers do (aside
>from amdgpu, which is fully dynamic), see drm_gem_map_attach in
>drm_prime.c
>
>Adding Christian as fyi.
>-Daniel
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
>> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116
>+-
>> 2 files changed, 143 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index 616c3a2f1baf..918c19df7b66 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -12,6 +12,8 @@
>> #include "i915_gem_object.h"
>> #include "i915_scatterlist.h"
>>
>> +I915_SELFTEST_DECLARE(static bool force_different_devices;)
>> +
>> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf
>*buf)
>> {
>> return to_intel_bo(buf->priv);
>> @@ -25,7 +27,14 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct dma_buf_attachment *attachme
>> struct scatterlist *src, *dst;
>> int ret, i;
>>
>> -ret = i915_gem_object_pin_pages_unlocked(obj);
>> +assert_object_held(obj);
>> +
>> +/*
>> + * Note. In the dynamic importer case, the object is not yet pinned.
>> + * Let's pin it here to avoid having to call the move_notify
>> + * callback, The call of which is not yet implemented.
>> + */
>> +ret = i915_gem_object_pin_pages(obj);
>> if (ret)
>> goto err;
>>
>> @@ -168,6 +177,21 @@ static int i915_gem_end_cpu_access(struct
>dma_buf *dma_buf, enum dma_data_direct
>> return err;
>> }
>>
>> +static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +assert_object_held(obj);
>> +return i915_gem_object_pin_pages(obj);
>> +}
>> +
>> +static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +i915_gem_object_unpin_pages(obj);
>> +}
>> +
>> static const struct
RE: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:54 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 9:50 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Thomas Hellström
>>> Sent: Monday, June 28, 2021 3:03 PM
>>> To: Ruhl, Michael J ; intel-
>>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>> Cc: Auld, Matthew ; lkp
>>> Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>
>>>
>>> On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
>>>>> -Original Message-
>>>>> From: dri-devel On Behalf
>Of
>>>>> Thomas Hellström
>>>>> Sent: Monday, June 28, 2021 10:46 AM
>>>>> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>>>> Cc: Thomas Hellström ; Auld,
>>> Matthew
>>>>> ; lkp
>>>>> Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>>>
>>>>> Introduce an interface to migrate objects between regions.
>>>>> This is primarily intended to migrate objects to LMEM for display and
>>>>> to SYSTEM for dma-buf, but might be reused in one form or another for
>>>>> performance-based migration.
>>>>>
>>>>> v2:
>>>>> - Verify that the memory region given as an id really exists.
>>>>>(Reported by Matthew Auld)
>>>>> - Call i915_gem_object_{init,release}_memory_region() when switching
>>>>> region
>>>>>to handle also switching region lists. (Reported by Matthew Auld)
>>>>> v3:
>>>>> - Fix i915_gem_object_can_migrate() to return true if object is already
>in
>>>>>the correct region, even if the object ops doesn't have a migrate()
>>>>>callback.
>>>>> - Update typo in commit message.
>>>>> - Fix kerneldoc of i915_gem_object_wait_migration().
>>>>>
>>>>> Reported-by: kernel test robot
>>>>> Signed-off-by: Thomas Hellström
>>>>> ---
>>>>> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>>>>> +++
>>>>> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
>>>>> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
>>>>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
>>>>> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
>>>>> 5 files changed, 188 insertions(+), 17 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> index 07e8ff9a8aae..1c18be067b58 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> @@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const
>struct
>>>>> drm_i915_gem_object *obj)
>>>>> return obj->mem_flags & I915_BO_FLAG_IOMEM;
>>>>> }
>>>>>
>>>>> +/**
>>>>> + * i915_gem_object_can_migrate - Whether an object likely can be
>>> migrated
>>>>> + *
>>>>> + * @obj: The object to migrate
>>>>> + * @id: The region intended to migrate to
>>>>> + *
>>>>> + * Check whether the object backend supports migration to the
>>>>> + * given region. Note that pinning may affect the ability to migrate.
>>>>> + *
>>>>> + * Return: true if migration is possible, false otherwise.
>>>>> + */
>>>>> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object
>*obj,
>>>>> + enum intel_region_id id)
>>>>> +{
>>>>> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>> + unsigned int num_allowed = obj->mm.n_placements;
>>>>> + struct intel_memory_region *mr;
>>>>> + unsigned int i;
>>>>> +
>>>>> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>>>>> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>>>>> +
>>>>> + mr = i915->mm.regions[id];
>>>>> + if (!mr)
>>>>>
RE: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:03 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: dri-devel On Behalf Of
>>> Thomas Hellström
>>> Sent: Monday, June 28, 2021 10:46 AM
>>> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>> Cc: Thomas Hellström ; Auld,
>Matthew
>>> ; lkp
>>> Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>
>>> Introduce an interface to migrate objects between regions.
>>> This is primarily intended to migrate objects to LMEM for display and
>>> to SYSTEM for dma-buf, but might be reused in one form or another for
>>> performance-based migration.
>>>
>>> v2:
>>> - Verify that the memory region given as an id really exists.
>>> (Reported by Matthew Auld)
>>> - Call i915_gem_object_{init,release}_memory_region() when switching
>>> region
>>> to handle also switching region lists. (Reported by Matthew Auld)
>>> v3:
>>> - Fix i915_gem_object_can_migrate() to return true if object is already in
>>> the correct region, even if the object ops doesn't have a migrate()
>>> callback.
>>> - Update typo in commit message.
>>> - Fix kerneldoc of i915_gem_object_wait_migration().
>>>
>>> Reported-by: kernel test robot
>>> Signed-off-by: Thomas Hellström
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>>> +++
>>> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
>>> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
>>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
>>> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
>>> 5 files changed, 188 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> index 07e8ff9a8aae..1c18be067b58 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> @@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const struct
>>> drm_i915_gem_object *obj)
>>> return obj->mem_flags & I915_BO_FLAG_IOMEM;
>>> }
>>>
>>> +/**
>>> + * i915_gem_object_can_migrate - Whether an object likely can be
>migrated
>>> + *
>>> + * @obj: The object to migrate
>>> + * @id: The region intended to migrate to
>>> + *
>>> + * Check whether the object backend supports migration to the
>>> + * given region. Note that pinning may affect the ability to migrate.
>>> + *
>>> + * Return: true if migration is possible, false otherwise.
>>> + */
>>> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
>>> +enum intel_region_id id)
>>> +{
>>> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>> + unsigned int num_allowed = obj->mm.n_placements;
>>> + struct intel_memory_region *mr;
>>> + unsigned int i;
>>> +
>>> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>>> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>>> +
>>> + mr = i915->mm.regions[id];
>>> + if (!mr)
>>> + return false;
>>> +
>>> + if (obj->mm.region == mr)
>>> + return true;
>>> +
>>> + if (!i915_gem_object_evictable(obj))
>>> + return false;
>>> +
>>> + if (!obj->ops->migrate)
>>> + return false;
>>> +
>>> + if (!(obj->flags & I915_BO_ALLOC_USER))
>>> + return true;
>>> +
>>> + if (num_allowed == 0)
>>> + return false;
>>> +
>>> + for (i = 0; i < num_allowed; ++i) {
>>> + if (mr == obj->mm.placements[i])
>>> + return true;
>>> + }
>> Hi Thomas,
>>
>> I am a little confused over the difference in checks between this function
>> and i915_gem_object_migrate().
>>
>> Why is the lack of an mr a BUG_ON in _object_migrate(), but here it just
>> false?
>>
>> So that means that under cert
RE: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: dri-devel On Behalf Of >Thomas Hellström >Sent: Monday, June 28, 2021 10:46 AM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Thomas Hellström ; Auld, Matthew > >Subject: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map >time > >Until we support p2p dma or as a complement to that, migrate data >to system memory at dma-buf map time if possible. > >v2: >- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver > selftest to migrate if we are LMEM capable. > >Signed-off-by: Thomas Hellström >--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 ++- > drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 +++- > 2 files changed, 9 insertions(+), 2 deletions(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >index 1d1eeb167d28..5207aa3af009 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >@@ -29,7 +29,12 @@ static struct sg_table *i915_gem_map_dma_buf(struct >dma_buf_attachment *attachme > > assert_object_held(obj); > >- ret = i915_gem_object_pin_pages(obj); >+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) >+ return ERR_PTR(-EOPNOTSUPP); >+ >+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >+ if (!ret) >+ ret = i915_gem_object_pin_pages(obj); > if (ret) > goto err; With the caveats of the previous patches this looks good. Reviewed-by: Michael J. Ruhl Mike >diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >index 24735d6c12a2..b6278dba98d0 100644 >--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >@@ -94,7 +94,9 @@ static int igt_dmabuf_import_same_driver(void *arg) > int err; > > force_different_devices = true; >- obj = i915_gem_object_create_shmem(i915, PAGE_SIZE); >+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0); >+ if (IS_ERR(obj)) >+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE); > if (IS_ERR(obj)) > goto out_ret; > >-- >2.31.1
RE: [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance dma-buf export
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ;
>maarten.lankho...@linux.intel.com; Thomas Hellström
>; Ruhl; Ruhl, Michael J
>
>Subject: [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance
>dma-buf export
>
>If our exported dma-bufs are imported by another instance of our driver,
>that instance will typically have the imported dma-bufs locked during
>map_attachment(). But the exporter also locks the same reservation
>object in the map_dma_buf() callback, which leads to recursive locking.
>
>Add a live selftest to catch this case, and as a workaround until
>we fully support dynamic import and export, declare the exporter dynamic
>by providing NOP pin() and unpin() functions. This means our map_dma_buf()
>callback will *always* get called locked, and by pinning unconditionally
>in i915_gem_map_dma_buf() we make sure we don't need to use the
>move_notify() functionality which is not yet implemented.
An interesting abuse of the interface, but it seems reasonable (for now) to me.
Reviewed-by: Michael J. Ruhl
Mike
>Reported-by: Ruhl, Michael J
>Cc: Ruhl, Michael J
>Signed-off-by: Thomas Hellström
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 ++-
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 81
>++-
> 2 files changed, 108 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 616c3a2f1baf..1d1eeb167d28 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -12,6 +12,8 @@
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>
>+I915_SELFTEST_DECLARE(static bool force_different_devices;)
>+
> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> {
> return to_intel_bo(buf->priv);
>@@ -25,7 +27,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> struct scatterlist *src, *dst;
> int ret, i;
>
>- ret = i915_gem_object_pin_pages_unlocked(obj);
>+ assert_object_held(obj);
>+
>+ ret = i915_gem_object_pin_pages(obj);
> if (ret)
> goto err;
>
>@@ -168,6 +172,26 @@ static int i915_gem_end_cpu_access(struct dma_buf
>*dma_buf, enum dma_data_direct
> return err;
> }
>
>+/*
>+ * As a workaround until we fully support dynamic import and export,
>+ * declare the exporter dynamic by providing NOP pin() and unpin()
>functions.
>+ * This means our i915_gem_map_dma_buf() callback will *always* get
>called
>+ * locked, and by pinning unconditionally in i915_gem_map_dma_buf() we
>make
>+ * sure we don't need to use the move_notify() functionality which is
>+ * not yet implemented. Typically for the same-driver-another-instance case,
>+ * i915_gem_map_dma_buf() will be called at importer attach time and the
>+ * mapped sg_list will be cached by the dma-buf core for the
>+ * duration of the attachment.
>+ */
>+static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
>+{
>+ return 0;
>+}
>+
>+static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
>+{
>+}
>+
> static const struct dma_buf_ops i915_dmabuf_ops = {
> .map_dma_buf = i915_gem_map_dma_buf,
> .unmap_dma_buf = i915_gem_unmap_dma_buf,
>@@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> .vunmap = i915_gem_dmabuf_vunmap,
> .begin_cpu_access = i915_gem_begin_cpu_access,
> .end_cpu_access = i915_gem_end_cpu_access,
>+ .pin = i915_gem_dmabuf_pin,
>+ .unpin = i915_gem_dmabuf_unpin,
> };
>
> struct dma_buf *i915_gem_prime_export(struct drm_gem_object
>*gem_obj, int flags)
>@@ -241,7 +267,8 @@ struct drm_gem_object
>*i915_gem_prime_import(struct drm_device *dev,
> if (dma_buf->ops == _dmabuf_ops) {
> obj = dma_buf_to_obj(dma_buf);
> /* is it from our device? */
>- if (obj->base.dev == dev) {
>+ if (obj->base.dev == dev &&
>+ !I915_SELFTEST_ONLY(force_different_devices)) {
> /*
>* Importing dmabuf exported from out own gem
>increases
>* refcount on gem itself instead of f_count of
>dmabuf.
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index dd74bc09ec88..24735d6c12a2 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/d
RE: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:15 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for
>the gem object migrate functionality
>
>On Mon, 2021-06-28 at 18:53 +, Ruhl, Michael J wrote:
>> > -Original Message-
>> > From: Intel-gfx On Behalf
>> > Of
>> > Thomas Hellström
>> > Sent: Monday, June 28, 2021 10:46 AM
>> > To: intel-...@lists.freedesktop.org;
>> > dri-devel@lists.freedesktop.org
>> > Cc: Thomas Hellström ; Auld,
>> > Matthew
>> >
>> > Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a
>> > selftest for the
>> > gem object migrate functionality
>> >
>> > From: Matthew Auld
>> >
>> > A selftest for the gem object migrate functionality. Slightly
>> > adapted
>> > from the original by Matthew to the new interface and new fill blit
>> > code.
>> >
>> > Co-developed-by: Thomas Hellström
>> >
>> > Signed-off-by: Thomas Hellström
>> > Signed-off-by: Matthew Auld
>> > ---
>> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
>> > .../drm/i915/gem/selftests/i915_gem_migrate.c | 237
>> > ++
>> > .../drm/i915/selftests/i915_live_selftests.h | 1 +
>> > 3 files changed, 239 insertions(+)
>> > create mode 100644
>> > drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > index 1c18be067b58..ff147fd59874 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > @@ -649,6 +649,7 @@ static const struct drm_gem_object_funcs
>> > i915_gem_object_funcs = {
>> > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>> > #include "selftests/huge_gem_object.c"
>> > #include "selftests/huge_pages.c"
>> > +#include "selftests/i915_gem_migrate.c"
>> > #include "selftests/i915_gem_object.c"
>> > #include "selftests/i915_gem_coherency.c"
>> > #endif
>> > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > new file mode 100644
>> > index ..a437b66f64d9
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > @@ -0,0 +1,237 @@
>> > +// SPDX-License-Identifier: MIT
>> > +/*
>> > + * Copyright © 2020-2021 Intel Corporation
>> > + */
>> > +
>> > +#include "gt/intel_migrate.h"
>> > +
>> > +static int igt_smem_create_migrate(void *arg)
>> > +{
>> > + struct intel_gt *gt = arg;
>> > + struct drm_i915_private *i915 = gt->i915;
>> > + struct drm_i915_gem_object *obj;
>> > + struct i915_gem_ww_ctx ww;
>> > + int err = 0;
>> > +
>> > + /* Switch object backing-store on create */
>> > + obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
>> > + if (IS_ERR(obj))
>> > + return PTR_ERR(obj);
>> > +
>> > + for_i915_gem_ww(, err, true) {
>> > + err = i915_gem_object_lock(obj, );
>> > + if (err)
>> > + continue;
>> > +
>> > + if (!i915_gem_object_can_migrate(obj,
>> > INTEL_REGION_SMEM)) {
>> > + err = -EINVAL;
>> > + continue;
>> > + }
>> > +
>> > + err = i915_gem_object_migrate(obj, ,
>> > INTEL_REGION_SMEM);
>> > + if (err)
>> > + continue;
>> > +
>> > + err = i915_gem_object_pin_pages(obj);
>> > + if (err)
>> > + continue;
>> > +
>> > + if (i915_gem_object_can_migrate(obj,
>> > INTEL_REGION_LMEM))
>> > + err = -EINVAL;
>> > +
>> > + i915_gem_object_unpin_pages(obj);
>> > + }
>> > + i915_gem_object_put(obj);
>> > +
>> > +
RE: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the
>gem object migrate functionality
>
>From: Matthew Auld
>
>A selftest for the gem object migrate functionality. Slightly adapted
>from the original by Matthew to the new interface and new fill blit
>code.
>
>Co-developed-by: Thomas Hellström
>Signed-off-by: Thomas Hellström
>Signed-off-by: Matthew Auld
>---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
> .../drm/i915/gem/selftests/i915_gem_migrate.c | 237
>++
> .../drm/i915/selftests/i915_live_selftests.h | 1 +
> 3 files changed, 239 insertions(+)
> create mode 100644
>drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 1c18be067b58..ff147fd59874 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -649,6 +649,7 @@ static const struct drm_gem_object_funcs
>i915_gem_object_funcs = {
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/huge_gem_object.c"
> #include "selftests/huge_pages.c"
>+#include "selftests/i915_gem_migrate.c"
> #include "selftests/i915_gem_object.c"
> #include "selftests/i915_gem_coherency.c"
> #endif
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>new file mode 100644
>index ..a437b66f64d9
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>@@ -0,0 +1,237 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright © 2020-2021 Intel Corporation
>+ */
>+
>+#include "gt/intel_migrate.h"
>+
>+static int igt_smem_create_migrate(void *arg)
>+{
>+ struct intel_gt *gt = arg;
>+ struct drm_i915_private *i915 = gt->i915;
>+ struct drm_i915_gem_object *obj;
>+ struct i915_gem_ww_ctx ww;
>+ int err = 0;
>+
>+ /* Switch object backing-store on create */
>+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
>+ if (IS_ERR(obj))
>+ return PTR_ERR(obj);
>+
>+ for_i915_gem_ww(, err, true) {
>+ err = i915_gem_object_lock(obj, );
>+ if (err)
>+ continue;
>+
>+ if (!i915_gem_object_can_migrate(obj,
>INTEL_REGION_SMEM)) {
>+ err = -EINVAL;
>+ continue;
>+ }
>+
>+ err = i915_gem_object_migrate(obj, ,
>INTEL_REGION_SMEM);
>+ if (err)
>+ continue;
>+
>+ err = i915_gem_object_pin_pages(obj);
>+ if (err)
>+ continue;
>+
>+ if (i915_gem_object_can_migrate(obj,
>INTEL_REGION_LMEM))
>+ err = -EINVAL;
>+
>+ i915_gem_object_unpin_pages(obj);
>+ }
>+ i915_gem_object_put(obj);
>+
>+ return err;
>+}
>+
>+static int igt_lmem_create_migrate(void *arg)
>+{
>+ struct intel_gt *gt = arg;
>+ struct drm_i915_private *i915 = gt->i915;
>+ struct drm_i915_gem_object *obj;
>+ struct i915_gem_ww_ctx ww;
>+ int err = 0;
>+
>+ /* Switch object backing-store on create */
>+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
>+ if (IS_ERR(obj))
>+ return PTR_ERR(obj);
>+
>+ for_i915_gem_ww(, err, true) {
>+ err = i915_gem_object_lock(obj, );
>+ if (err)
>+ continue;
>+
>+ if (!i915_gem_object_can_migrate(obj,
>INTEL_REGION_LMEM)) {
>+ err = -EINVAL;
>+ continue;
>+ }
>+
>+ err = i915_gem_object_migrate(obj, ,
>INTEL_REGION_LMEM);
>+ if (err)
>+ continue;
>+
>+ err = i915_gem_object_pin_pages(obj);
>+ if (err)
>+ continue;
>+
>+ if (i915_gem_object_can_migrate(obj,
>INTEL_REGION_SMEM))
>+ err = -EINVAL;
>+
>+ i915_gem_object_unpin_pages(obj);
>+ }
>+ i915_gem_object_put(obj);
>+
>+ return err;
>+}
>+
>+static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
>+struct drm_i915_gem_object *obj)
>+{
>+ int err;
>+
>+ err = i915_gem_object_lock(obj, ww);
>+ if (err)
>+ return err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE |
>+ I915_WAIT_PRIORITY |
>+ I915_WAIT_ALL,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ if (i915_gem_object_is_lmem(obj)) {
>+ if
RE: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>; lkp
>Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>Introduce an interface to migrate objects between regions.
>This is primarily intended to migrate objects to LMEM for display and
>to SYSTEM for dma-buf, but might be reused in one form or another for
>performance-based migration.
>
>v2:
>- Verify that the memory region given as an id really exists.
> (Reported by Matthew Auld)
>- Call i915_gem_object_{init,release}_memory_region() when switching
>region
> to handle also switching region lists. (Reported by Matthew Auld)
>v3:
>- Fix i915_gem_object_can_migrate() to return true if object is already in
> the correct region, even if the object ops doesn't have a migrate()
> callback.
>- Update typo in commit message.
>- Fix kerneldoc of i915_gem_object_wait_migration().
>
>Reported-by: kernel test robot
>Signed-off-by: Thomas Hellström
>---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>+++
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
> 5 files changed, 188 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 07e8ff9a8aae..1c18be067b58 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const struct
>drm_i915_gem_object *obj)
> return obj->mem_flags & I915_BO_FLAG_IOMEM;
> }
>
>+/**
>+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
>+ *
>+ * @obj: The object to migrate
>+ * @id: The region intended to migrate to
>+ *
>+ * Check whether the object backend supports migration to the
>+ * given region. Note that pinning may affect the ability to migrate.
>+ *
>+ * Return: true if migration is possible, false otherwise.
>+ */
>+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
>+ enum intel_region_id id)
>+{
>+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
>+ unsigned int num_allowed = obj->mm.n_placements;
>+ struct intel_memory_region *mr;
>+ unsigned int i;
>+
>+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>+
>+ mr = i915->mm.regions[id];
>+ if (!mr)
>+ return false;
>+
>+ if (obj->mm.region == mr)
>+ return true;
>+
>+ if (!i915_gem_object_evictable(obj))
>+ return false;
>+
>+ if (!obj->ops->migrate)
>+ return false;
>+
>+ if (!(obj->flags & I915_BO_ALLOC_USER))
>+ return true;
>+
>+ if (num_allowed == 0)
>+ return false;
>+
>+ for (i = 0; i < num_allowed; ++i) {
>+ if (mr == obj->mm.placements[i])
>+ return true;
>+ }
Hi Thomas,
I am a little confused over the difference in checks between this function
and i915_gem_object_migrate().
Why is the lack of an mr a BUG_ON in _object_migrate(), but here it just
false?
So that means that under certain circumstances, you could not have a mr?
If that is the case, when?
Would that be when the I915_BO_ALLOC_USER is set?
If so, should there be a check for "non" user vs user?
Or maybe document this function pointing out why there are differences
and why?
>+ return false;
>+}
>+
>+/**
>+ * i915_gem_object_migrate - Migrate an object to the desired region id
>+ * @obj: The object to migrate.
>+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
>+ * not be successful in evicting other objects to make room for this object.
Is the ww for future consideration? (I don't see any use of it in the patch).
>+ * @id: The region id to migrate to.
>+ *
>+ * Attempt to migrate the object to the desired memory region. The
>+ * object backend must support migration and the object may not be
>+ * pinned, (explicitly pinned pages or pinned vmas). The object must
>+ * be locked.
>+ * On successful completion, the object will have pages pointing to
>+ * memory in the new region, but an async migration task may not have
>+ * completed yet, and to accomplish that,
>i915_gem_object_wait_migration()
>+ * must be called.
>+ *
>+ * Return: 0 on success. Negative error code on failure. In particular may
>+ * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
>+ * if @ww is set, -EINTR or -ERESTARTSYS if signal pending, and
>+ * -EBUSY if the object is pinned.
>+ */
>+int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
>+ struct
RE: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 3:10 PM>To: Ruhl, Michael J >; intel- >g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 9:07 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 2:50 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Mike, >>> >>> On 6/25/21 7:57 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: Thomas Hellström >>>>> Sent: Friday, June 25, 2021 1:52 PM >>>>> To: Ruhl, Michael J ; intel- >>>>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>>>> Cc: Auld, Matthew >>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>> time >>>>> >>>>> >>>>> On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>>>>>> -Original Message- >>>>>>> From: Thomas Hellström >>>>>>> Sent: Friday, June 25, 2021 12:18 PM >>>>>>> To: Ruhl, Michael J ; intel- >>>>>>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>>>>>> Cc: Auld, Matthew >>>>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma- >buf >>>>> map >>>>>>> time >>>>>>> >>>>>>> Hi, Michael, >>>>>>> >>>>>>> thanks for looking at this. >>>>>>> >>>>>>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>>>>>> -Original Message- >>>>>>>>> From: dri-devel On >>> Behalf >>>>> Of >>>>>>>>> Thomas Hellström >>>>>>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>>>>>> To: intel-...@lists.freedesktop.org; dri- >de...@lists.freedesktop.org >>>>>>>>> Cc: Thomas Hellström ; Auld, >>>>>>> Matthew >>>>>>>>> >>>>>>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>>>> time >>>>>>>>> Until we support p2p dma or as a complement to that, migrate data >>>>>>>>> to system memory at dma-buf map time if possible. >>>>>>>>> >>>>>>>>> Signed-off-by: Thomas Hellström >>> >>>>>>>>> --- >>>>>>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> @@ -25,7 +25,14 @@ static struct sg_table >>>>>>> *i915_gem_map_dma_buf(struct >>>>>>>>> dma_buf_attachment *attachme >>>>>>>>> struct scatterlist *src, *dst; >>>>>>>>> int ret, i; >>>>>>>>> >>>>>>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>>>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>>>>>> Hmm, I believe in most cases that the caller should be holding the >>>>>>>> lock (object dma-resv) on this object already. >>>>>>> Yes, I agree, In particular for other instances of our own driver, at >>>>>>> least since the dma_resv introduction. >>>>>>> >>>>>>> But I also think that's a pre-existing bug, since >>>>>>> i915_gem_object_pin_pages_unlocked() will also take the lock. >&g
RE: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 2:50 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Mike, > >On 6/25/21 7:57 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 1:52 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> >>> On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: Thomas Hellström >>>>> Sent: Friday, June 25, 2021 12:18 PM >>>>> To: Ruhl, Michael J ; intel- >>>>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>>>> Cc: Auld, Matthew >>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>> time >>>>> >>>>> Hi, Michael, >>>>> >>>>> thanks for looking at this. >>>>> >>>>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>>>> -Original Message- >>>>>>> From: dri-devel On >Behalf >>> Of >>>>>>> Thomas Hellström >>>>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>>>> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>>>>>> Cc: Thomas Hellström ; Auld, >>>>> Matthew >>>>>>> >>>>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>>>> time >>>>>>> Until we support p2p dma or as a complement to that, migrate data >>>>>>> to system memory at dma-buf map time if possible. >>>>>>> >>>>>>> Signed-off-by: Thomas Hellström > >>>>>>> --- >>>>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> @@ -25,7 +25,14 @@ static struct sg_table >>>>> *i915_gem_map_dma_buf(struct >>>>>>> dma_buf_attachment *attachme >>>>>>> struct scatterlist *src, *dst; >>>>>>> int ret, i; >>>>>>> >>>>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>>>> Hmm, I believe in most cases that the caller should be holding the >>>>>> lock (object dma-resv) on this object already. >>>>> Yes, I agree, In particular for other instances of our own driver, at >>>>> least since the dma_resv introduction. >>>>> >>>>> But I also think that's a pre-existing bug, since >>>>> i915_gem_object_pin_pages_unlocked() will also take the lock. >>>> Ouch yes. Missed that. >>>> >>>>> I Think we need to initially make the exporter dynamic-capable to >>>>> resolve this, and drop the locking here completely, as dma-buf docs says >>>>> that we're then guaranteed to get called with the object lock held. >>>>> >>>>> I figure if we make the exporter dynamic, we need to migrate already at >>>>> dma_buf_pin time so we don't pin the object in the wrong location. >>>> The exporter as dynamic (ops->pin is available) is optional, but importer >>>> dynamic (ops->move_notify) is required. >>>> >>>> With that in mind, it would seem that there are three possible >combinations >>>> for the migrate to be attempted: >>>> >>>> 1) in the ops->pin function (export_dynamic != import_dynamic, during >>> attach) >>>> 2) in the ops->pin function (export_dynamic
RE: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 1:52 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 12:18 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Michael, >>> >>> thanks for looking at this. >>> >>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: dri-devel On Behalf >Of >>>>> Thomas Hellström >>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>>>> Cc: Thomas Hellström ; Auld, >>> Matthew >>>>> >>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >>> time >>>>> Until we support p2p dma or as a complement to that, migrate data >>>>> to system memory at dma-buf map time if possible. >>>>> >>>>> Signed-off-by: Thomas Hellström >>>>> --- >>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> @@ -25,7 +25,14 @@ static struct sg_table >>> *i915_gem_map_dma_buf(struct >>>>> dma_buf_attachment *attachme >>>>> struct scatterlist *src, *dst; >>>>> int ret, i; >>>>> >>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>> Hmm, I believe in most cases that the caller should be holding the >>>> lock (object dma-resv) on this object already. >>> Yes, I agree, In particular for other instances of our own driver, at >>> least since the dma_resv introduction. >>> >>> But I also think that's a pre-existing bug, since >>> i915_gem_object_pin_pages_unlocked() will also take the lock. >> Ouch yes. Missed that. >> >>> I Think we need to initially make the exporter dynamic-capable to >>> resolve this, and drop the locking here completely, as dma-buf docs says >>> that we're then guaranteed to get called with the object lock held. >>> >>> I figure if we make the exporter dynamic, we need to migrate already at >>> dma_buf_pin time so we don't pin the object in the wrong location. >> The exporter as dynamic (ops->pin is available) is optional, but importer >> dynamic (ops->move_notify) is required. >> >> With that in mind, it would seem that there are three possible combinations >> for the migrate to be attempted: >> >> 1) in the ops->pin function (export_dynamic != import_dynamic, during >attach) >> 2) in the ops->pin function (export_dynamic and >!CONFIG_DMABUF_MOVE_NOTIFY) during mapping >> 3) and possibly in ops->map_dma_buf (exort_dynamic iand >CONFIG_DMABUF_MOVE_NOTIFY) >> >> Since one possibility has to be in the mapping function, it seems that if we >> can figure out the locking, that the migrate should probably be available >here. >> >> Mike > >So perhaps just to initially fix the bug, we could just implement NOP >pin() and unpin() callbacks and drop the locking in map_attach() and >replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma-buf.c#L730) If you don't have that, i.e. just the pin interface, the attach will be rejected, and you will not get the callbacks. So I think that the only thing we can do for now is to dop the locking and add the assert_object_held(); M >/Thomas >
RE: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 12:18 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Michael, > >thanks for looking at this. > >On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: dri-devel On Behalf Of >>> Thomas Hellström >>> Sent: Thursday, June 24, 2021 2:31 PM >>> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >>> Cc: Thomas Hellström ; Auld, >Matthew >>> >>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time >>> >>> Until we support p2p dma or as a complement to that, migrate data >>> to system memory at dma-buf map time if possible. >>> >>> Signed-off-by: Thomas Hellström >>> --- >>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> index 616c3a2f1baf..a52f885bc09a 100644 >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> @@ -25,7 +25,14 @@ static struct sg_table >*i915_gem_map_dma_buf(struct >>> dma_buf_attachment *attachme >>> struct scatterlist *src, *dst; >>> int ret, i; >>> >>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >> Hmm, I believe in most cases that the caller should be holding the >> lock (object dma-resv) on this object already. > >Yes, I agree, In particular for other instances of our own driver, at >least since the dma_resv introduction. > >But I also think that's a pre-existing bug, since >i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. >I Think we need to initially make the exporter dynamic-capable to >resolve this, and drop the locking here completely, as dma-buf docs says >that we're then guaranteed to get called with the object lock held. > >I figure if we make the exporter dynamic, we need to migrate already at >dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike >/Thomas > > >> >> I know for the dynamic version of dma-buf, there is a check to make >> sure that the lock is held when called. >> >> I think you will run into some issues if you try to get it here as well. >> >> Mike >> >>> + if (ret) >>> + return ERR_PTR(ret); >>> + >>> + ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >>> + if (!ret) >>> + ret = i915_gem_object_pin_pages(obj); >>> + i915_gem_object_unlock(obj); >>> if (ret) >>> goto err; >>> >>> -- >>> 2.31.1
RE: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: dri-devel On Behalf Of >Thomas Hellström >Sent: Thursday, June 24, 2021 2:31 PM >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org >Cc: Thomas Hellström ; Auld, Matthew > >Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time > >Until we support p2p dma or as a complement to that, migrate data >to system memory at dma-buf map time if possible. > >Signed-off-by: Thomas Hellström >--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >index 616c3a2f1baf..a52f885bc09a 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >@@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct >dma_buf_attachment *attachme > struct scatterlist *src, *dst; > int ret, i; > >- ret = i915_gem_object_pin_pages_unlocked(obj); >+ ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. I know for the dynamic version of dma-buf, there is a check to make sure that the lock is held when called. I think you will run into some issues if you try to get it here as well. Mike >+ if (ret) >+ return ERR_PTR(ret); >+ >+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >+ if (!ret) >+ ret = i915_gem_object_pin_pages(obj); >+ i915_gem_object_unlock(obj); > if (ret) > goto err; > >-- >2.31.1
RE: [PATCH v8 1/5] drm/ast: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: lkp ; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; Thomas Zimmermann
>; Dave Airlie
>Subject: [PATCH v8 1/5] drm/ast: Remove reference to struct
>drm_device.pdev
>
>Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
>from struct drm_device.dev to get the PCI device structure.
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>Fixes: ba4e0339a6a3 ("drm/ast: Fixed CVE for DP501")
>Cc: KuoHsiang Chou
>Cc: kernel test robot
>Cc: Thomas Zimmermann
>Cc: Dave Airlie
>Cc: dri-devel@lists.freedesktop.org
>---
> drivers/gpu/drm/ast/ast_main.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/ast/ast_main.c
>b/drivers/gpu/drm/ast/ast_main.c
>index 189d783f6e2c..6b49a92dc75f 100644
>--- a/drivers/gpu/drm/ast/ast_main.c
>+++ b/drivers/gpu/drm/ast/ast_main.c
>@@ -411,7 +411,6 @@ struct ast_private *ast_device_create(const struct
>drm_driver *drv,
> return ast;
> dev = >base;
>
>- dev->pdev = pdev;
> pci_set_drvdata(pdev, dev);
>
> ast->regs = pcim_iomap(pdev, 1, 0);
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v8 3/5] drm/i915: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: intel-...@lists.freedesktop.org; Thomas Zimmermann
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH v8 3/5] drm/i915: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Fix a rsp
>comment.
>
>v8:
> * fix commit message (Michael)
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>---
> drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
>b/drivers/gpu/drm/i915/intel_runtime_pm.h
>index 1e4ddd11c12b..183ea2b187fe 100644
>--- a/drivers/gpu/drm/i915/intel_runtime_pm.h
>+++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
>@@ -49,7 +49,7 @@ enum i915_drm_suspend_mode {
> */
> struct intel_runtime_pm {
> atomic_t wakeref_count;
>- struct device *kdev; /* points to i915->drm.pdev->dev */
>+ struct device *kdev; /* points to i915->drm.dev */
> bool available;
> bool suspended;
> bool irqs_enabled;
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH v8 2/5] drm/i915/gt: Remove reference to struct drm_device.pdev
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: Winiarski, Michal ; Nikula, Jani
>; Daniel Vetter ; intel-
>g...@lists.freedesktop.org; De Marchi, Lucas ; dri-
>de...@lists.freedesktop.org; Auld, Matthew ;
>Thomas Zimmermann
>Subject: [Intel-gfx] [PATCH v8 2/5] drm/i915/gt: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
>
>v8:
> * fix commit message (Michael)
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>Fixes: a50ca39fbd01 ("drm/i915: setup the LMEM region")
>Cc: Lucas De Marchi
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Matthew Auld
>Cc: Jani Nikula
>Cc: Chris Wilson
>Cc: Daniel Vetter
>Cc: Tvrtko Ursulin
>Cc: Daniele Ceraolo Spurio
>Cc: Mika Kuoppala
>Cc: Maarten Lankhorst
>Cc: Venkata Sandeep Dhanalakota
>Cc: "Michał Winiarski"
>---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>index be6f2c8f5184..73fceb0c25fc 100644
>--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>@@ -177,7 +177,7 @@ static struct intel_memory_region
>*setup_lmem(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> struct intel_uncore *uncore = gt->uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
>
>___
>Intel-gfx mailing list
>intel-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/i915/gem: Remove reference to struct drm_device.pdev
>-Original Message-
>From: Thomas Zimmermann
>Sent: Tuesday, April 27, 2021 1:49 PM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>; Ruhl, Michael J
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Thomas
>Zimmermann ; Nikula, Jani
>; Tang, CQ ; Tvrtko Ursulin
>; Liu, Xinyun ; Ursulin,
>Tvrtko ; Chris Wilson ;
>Mika Kuoppala ; Daniel Vetter
>; Maarten Lankhorst
>; Hellstrom, Thomas
>; Gustavo A. R. Silva
>; Dan Carpenter
>Subject: [PATCH v2] drm/i915/gem: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
Commit message match the patch.
Reviewed-by: Michael J. Ruhl v2:
> * fix an error in the commit description (Michael)
>
>Signed-off-by: Thomas Zimmermann
>Reviewed-by: Jani Nikula
>Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local
>memory")
>Cc: CQ Tang
>Cc: Matthew Auld
>Cc: Tvrtko Ursulin
>Cc: Xinyun Liu
>Cc: Tvrtko Ursulin
>Cc: Jani Nikula
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Chris Wilson
>Cc: Mika Kuoppala
>Cc: Daniel Vetter
>Cc: Maarten Lankhorst
>Cc: "Thomas Hellström"
>Cc: "Gustavo A. R. Silva"
>Cc: Dan Carpenter
>Cc: intel-...@lists.freedesktop.org
>---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>index c5b64b2400e8..e1a32672bbe8 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>@@ -773,7 +773,7 @@ struct intel_memory_region *
> i915_gem_stolen_lmem_setup(struct drm_i915_private *i915)
> {
> struct intel_uncore *uncore = >uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Tuesday, April 27, 2021 7:08 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>
>Cc: Tvrtko Ursulin ; Ursulin, Tvrtko
>; Mika Kuoppala
>; intel-...@lists.freedesktop.org; Gustavo
>A. R. Silva ; dri-devel@lists.freedesktop.org; Chris
>Wilson ; Tang, CQ ; Hellstrom,
>Thomas ; Thomas Zimmermann
>; Daniel Vetter ; Liu,
>Xinyun ; Dan Carpenter
>Subject: [PATCH] drm/i915/gem: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should be used any longer as
should not be used
^^^
?
m
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
>
>Signed-off-by: Thomas Zimmermann
>Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local
>memory")
>Cc: CQ Tang
>Cc: Matthew Auld
>Cc: Tvrtko Ursulin
>Cc: Xinyun Liu
>Cc: Tvrtko Ursulin
>Cc: Jani Nikula
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Chris Wilson
>Cc: Mika Kuoppala
>Cc: Daniel Vetter
>Cc: Maarten Lankhorst
>Cc: "Thomas Hellström"
>Cc: "Gustavo A. R. Silva"
>Cc: Dan Carpenter
>Cc: intel-...@lists.freedesktop.org
>---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>index c5b64b2400e8..e1a32672bbe8 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>@@ -773,7 +773,7 @@ struct intel_memory_region *
> i915_gem_stolen_lmem_setup(struct drm_i915_private *i915)
> {
> struct intel_uncore *uncore = >uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/ttm: cleanup ttm_agp_backend
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, April 26, 2021 1:58 PM
>To: dri-devel@lists.freedesktop.org
>Cc: bske...@redhat.com
>Subject: [PATCH] drm/ttm: cleanup ttm_agp_backend
>
>Audit the includes and stop accessing the internal drm_mm_node.
>
>The ttm_resource::start should be the same value as the
>drm_mm_node::start.
"should be"?
Are you sure?
If it isn't, is there an issue?
If they are the same (set in ttm_range_man_alloc?), maybe:
The ttm_resource::start is the same value as the drm_mm_node::start.
With that change:
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_agp_backend.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>index 0226ae69d3ab..6ddc16f0fe2b 100644
>--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>@@ -32,8 +32,9 @@
>
> #define pr_fmt(fmt) "[TTM] " fmt
>
>-#include
>-#include
>+#include
>+#include
>+#include
> #include
> #include
> #include
>@@ -50,7 +51,6 @@ int ttm_agp_bind(struct ttm_tt *ttm, struct
>ttm_resource *bo_mem)
> {
> struct ttm_agp_backend *agp_be = container_of(ttm, struct
>ttm_agp_backend, ttm);
> struct page *dummy_read_page = ttm_glob.dummy_read_page;
>- struct drm_mm_node *node = bo_mem->mm_node;
> struct agp_memory *mem;
> int ret, cached = ttm->caching == ttm_cached;
> unsigned i;
>@@ -76,7 +76,7 @@ int ttm_agp_bind(struct ttm_tt *ttm, struct
>ttm_resource *bo_mem)
> mem->is_flushed = 1;
> mem->type = (cached) ? AGP_USER_CACHED_MEMORY :
>AGP_USER_MEMORY;
>
>- ret = agp_bind_memory(mem, node->start);
>+ ret = agp_bind_memory(mem, bo_mem->start);
> if (ret)
> pr_err("AGP Bind memory failed\n");
>
>--
>2.25.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/nouveau: fix dma syncing for loops (v2)
>-Original Message-
>From: Dave Airlie
>Sent: Wednesday, March 10, 2021 11:35 PM
>To: dri-devel@lists.freedesktop.org
>Cc: Ruhl, Michael J ; skeg...@gmail.com
>Subject: [PATCH] drm/nouveau: fix dma syncing for loops (v2)
>
>From: Dave Airlie
>
>The index variable should only be increased in one place.
>
>Noticed this while trying to track down another oops.
>
>v2: use while loop.
Ok, that makes it more obvious for me.
Thanks.
Reviewed-by: Michael J. Ruhl
M
>Fixes: f295c8cfec83 ("drm/nouveau: fix dma syncing warning with debugging
>on.")
>Signed-off-by: Dave Airlie
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 2375711877cf..fabb314a0b2f 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -556,7 +556,8 @@ nouveau_bo_sync_for_device(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ i = 0;
>+ while (i < ttm_dma->num_pages) {
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>@@ -587,7 +588,8 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ i = 0;
>+ while (i < ttm_dma->num_pages) {
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>--
>2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/nouveau: fix dma syncing for loops
>-Original Message-
>From: dri-devel On Behalf Of
>Dave Airlie
>Sent: Sunday, March 7, 2021 8:49 PM
>To: dri-devel@lists.freedesktop.org
>Cc: skeg...@gmail.com
>Subject: [PATCH] drm/nouveau: fix dma syncing for loops
>
>From: Dave Airlie
>
>The index variable should only be increased in one place.
>
>Noticed this while trying to track down another oops.
>
>Fixes: f295c8cfec83 ("drm/nouveau: fix dma syncing warning with debugging
>on.")
>Signed-off-by: Dave Airlie
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 2375711877cf..4f693843def5 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -556,7 +556,7 @@ nouveau_bo_sync_for_device(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ for (i = 0; i < ttm_dma->num_pages;) {
This took a bit to see how the increment worked.
Would calling it out with a comment be out of line?
With or without the comment:
Reviewed-by: Michael J. Ruhl
M
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>@@ -587,7 +587,7 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ for (i = 0; i < ttm_dma->num_pages;) {
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>--
>2.27.0
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Tuesday, January 12, 2021 2:45 AM
>To: Ruhl, Michael J ; sumit.sem...@linaro.org;
>christian.koe...@amd.com; airl...@redhat.com; dan...@ffwll.ch;
>maarten.lankho...@linux.intel.com; mrip...@kernel.org;
>kra...@redhat.com; hdego...@redhat.com; s...@poorly.run;
>e...@anholt.net; s...@ravnborg.org
>Cc: linaro-mm-...@lists.linaro.org; Daniel Vetter ;
>virtualizat...@lists.linux-foundation.org; dri-devel@lists.freedesktop.org;
>linux-me...@vger.kernel.org
>Subject: Re: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>operations
>
>Hi
>
>Am 08.01.21 um 17:12 schrieb Ruhl, Michael J:
>>> -Original Message-
>>> From: dri-devel On Behalf Of
>>> Thomas Zimmermann
>>> Sent: Friday, January 8, 2021 4:43 AM
>>> To: sumit.sem...@linaro.org; christian.koe...@amd.com;
>>> airl...@redhat.com; dan...@ffwll.ch; maarten.lankho...@linux.intel.com;
>>> mrip...@kernel.org; kra...@redhat.com; hdego...@redhat.com;
>>> s...@poorly.run; e...@anholt.net; s...@ravnborg.org
>>> Cc: Daniel Vetter ; dri-
>de...@lists.freedesktop.org;
>>> virtualizat...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org;
>>> Thomas Zimmermann ; linux-
>>> me...@vger.kernel.org
>>> Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>>> operations
>>>
>>> The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>>> allowed to pin the buffer or acquire the buffer's reservation object
>>> lock.
>>>
>>> This is a problem for callers that only require a short-term mapping
>>> of the buffer without the pinning, or callers that have special locking
>>> requirements. These may suffer from unnecessary overhead or interfere
>>> with regular pin operations.
>>>
>>> The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(),
>and
>>> their rsp callbacks in struct dma_buf_ops provide an alternative without
>>> pinning or reservation locking. Callers are responsible for these
>>> operations.
>>>
>>> v4:
>>> * update documentation (Daniel)
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> Reviewed-by: Daniel Vetter
>>> Suggested-by: Daniel Vetter
>>> ---
>>> drivers/dma-buf/dma-buf.c | 81
>>> +++
>>> include/linux/dma-buf.h | 34
>>> 2 files changed, 115 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index b8465243eca2..01f9c74d97fa 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf
>*dmabuf,
>>> struct dma_buf_map *map)
>>> }
>>> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>>>
>>> +/**
>>> + * dma_buf_vmap_local - Create virtual mapping for the buffer object
>into
>>> kernel
>>> + * address space.
>>> + * @dmabuf:[in]buffer to vmap
>>> + * @map: [out] returns the vmap pointer
>>> + *
>>> + * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>>> + * the buffer. The struct dma_resv for the @dmabuf must be locked until
>>> + * dma_buf_vunmap_local() is called.
>>> + *
>>> + * Returns:
>>> + * 0 on success, or a negative errno code otherwise.
>>> + */
>>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>>> *map)
>>> +{
>>> + struct dma_buf_map ptr;
>>> + int ret = 0;
>>> +
>>> + dma_buf_map_clear(map);
>>> +
>>> + if (WARN_ON(!dmabuf))
>>> + return -EINVAL;
>>> +
>>> + dma_resv_assert_held(dmabuf->resv);
>>> +
>>> + if (!dmabuf->ops->vmap_local)
>>> + return -EINVAL;
>>
>> You are clearing the map, and then doing the above checks.
>>
>> Is it ok to change the map info and then exit on error?
>
>In vmap_local map argument returns the mapping's address. Callers are
>expected to check the return code. But I would expect a careless caller
>to not check, or check for map being cleared. Clearing it here first is
>the save thing to do.
Ahh, a pre-emptive attempt to make sure the caller doesn't cause more
problems on error.
Thanks,
M
>Best regards
>Thomas
>
>>
>> Mike
>>
>>> + mutex_lock(>lock);
>&g
RE: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Friday, January 8, 2021 4:43 AM
>To: sumit.sem...@linaro.org; christian.koe...@amd.com;
>airl...@redhat.com; dan...@ffwll.ch; maarten.lankho...@linux.intel.com;
>mrip...@kernel.org; kra...@redhat.com; hdego...@redhat.com;
>s...@poorly.run; e...@anholt.net; s...@ravnborg.org
>Cc: Daniel Vetter ; dri-devel@lists.freedesktop.org;
>virtualizat...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org;
>Thomas Zimmermann ; linux-
>me...@vger.kernel.org
>Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>operations
>
>The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>allowed to pin the buffer or acquire the buffer's reservation object
>lock.
>
>This is a problem for callers that only require a short-term mapping
>of the buffer without the pinning, or callers that have special locking
>requirements. These may suffer from unnecessary overhead or interfere
>with regular pin operations.
>
>The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>their rsp callbacks in struct dma_buf_ops provide an alternative without
>pinning or reservation locking. Callers are responsible for these
>operations.
>
>v4:
> * update documentation (Daniel)
>
>Signed-off-by: Thomas Zimmermann
>Reviewed-by: Daniel Vetter
>Suggested-by: Daniel Vetter
>---
> drivers/dma-buf/dma-buf.c | 81
>+++
> include/linux/dma-buf.h | 34
> 2 files changed, 115 insertions(+)
>
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index b8465243eca2..01f9c74d97fa 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>struct dma_buf_map *map)
> }
> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>
>+/**
>+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>kernel
>+ * address space.
>+ * @dmabuf: [in]buffer to vmap
>+ * @map: [out] returns the vmap pointer
>+ *
>+ * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>+ * the buffer. The struct dma_resv for the @dmabuf must be locked until
>+ * dma_buf_vunmap_local() is called.
>+ *
>+ * Returns:
>+ * 0 on success, or a negative errno code otherwise.
>+ */
>+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>*map)
>+{
>+ struct dma_buf_map ptr;
>+ int ret = 0;
>+
>+ dma_buf_map_clear(map);
>+
>+ if (WARN_ON(!dmabuf))
>+ return -EINVAL;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ if (!dmabuf->ops->vmap_local)
>+ return -EINVAL;
You are clearing the map, and then doing the above checks.
Is it ok to change the map info and then exit on error?
Mike
>+ mutex_lock(>lock);
>+ if (dmabuf->vmapping_counter) {
>+ dmabuf->vmapping_counter++;
>+ BUG_ON(dma_buf_map_is_null(>vmap_ptr));
>+ *map = dmabuf->vmap_ptr;
>+ goto out_unlock;
>+ }
>+
>+ BUG_ON(dma_buf_map_is_set(>vmap_ptr));
>+
>+ ret = dmabuf->ops->vmap_local(dmabuf, );
>+ if (WARN_ON_ONCE(ret))
>+ goto out_unlock;
>+
>+ dmabuf->vmap_ptr = ptr;
>+ dmabuf->vmapping_counter = 1;
>+
>+ *map = dmabuf->vmap_ptr;
>+
>+out_unlock:
>+ mutex_unlock(>lock);
>+ return ret;
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>+
>+/**
>+ * dma_buf_vunmap_local - Unmap a vmap obtained by
>dma_buf_vmap_local.
>+ * @dmabuf: [in]buffer to vunmap
>+ * @map: [in]vmap pointer to vunmap
>+ *
>+ * Release a mapping established with dma_buf_vmap_local().
>+ */
>+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>dma_buf_map *map)
>+{
>+ if (WARN_ON(!dmabuf))
>+ return;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ BUG_ON(dma_buf_map_is_null(>vmap_ptr));
>+ BUG_ON(dmabuf->vmapping_counter == 0);
>+ BUG_ON(!dma_buf_map_is_equal(>vmap_ptr, map));
>+
>+ mutex_lock(>lock);
>+ if (--dmabuf->vmapping_counter == 0) {
>+ if (dmabuf->ops->vunmap_local)
>+ dmabuf->ops->vunmap_local(dmabuf, map);
>+ dma_buf_map_clear(>vmap_ptr);
>+ }
>+ mutex_unlock(>lock);
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>+
> #ifdef CONFIG_DEBUG_FS
> static int dma_buf_debug_show(struct seq_file *s, void *unused)
> {
>diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>index 628681bf6c99..aeed754b5467 100644
>--- a/include/linux/dma-buf.h
>+++ b/include/linux/dma-buf.h
>@@ -264,6 +264,38 @@ struct dma_buf_ops {
>
> int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+
>+ /**
>+ * @vmap_local:
>+ *
>+ * Creates a virtual mapping for the buffer into kernel address space.
>+ *
>+ * This callback establishes short-term mappings
RE: [PATCH] dma-buf: Fix kerneldoc formatting
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Friday, December 4, 2020 3:03 PM
>To: DRI Development
>Cc: Daniel Vetter ; Vetter, Daniel
>
>Subject: [PATCH] dma-buf: Fix kerneldoc formatting
>
>I wanted to look up something and noticed the hyperlink doesn't work.
>While fixing that also noticed a trivial kerneldoc comment typo in the
>same section, fix that too.
>
>Signed-off-by: Daniel Vetter
>---
> Documentation/driver-api/dma-buf.rst | 2 +-
> include/linux/dma-buf-map.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-
>api/dma-buf.rst
>index d6b2a195dbed..a2133d69872c 100644
>--- a/Documentation/driver-api/dma-buf.rst
>+++ b/Documentation/driver-api/dma-buf.rst
>@@ -190,7 +190,7 @@ DMA Fence uABI/Sync File
> Indefinite DMA Fences
> ~
>
>-At various times _fence with an indefinite time until dma_fence_wait()
>+At various times struct dma_fence with an indefinite time until
>dma_fence_wait()
> finishes have been proposed. Examples include:
>
> * Future fences, used in HWC1 to signal when a buffer isn't used by the
>display
>diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
Ahh, something to do while compiling...
Both changes look good to me.
Reviewed-by: Michael J. Ruhl
M
>index 583a3a1f9447..278d489e4bdd 100644
>--- a/include/linux/dma-buf-map.h
>+++ b/include/linux/dma-buf-map.h
>@@ -122,7 +122,7 @@ struct dma_buf_map {
>
> /**
> * DMA_BUF_MAP_INIT_VADDR - Initializes struct dma_buf_map to an
>address in system memory
>- * @vaddr:A system-memory address
>+ * @vaddr_: A system-memory address
> */
> #define DMA_BUF_MAP_INIT_VADDR(vaddr_) \
> { \
>--
>2.29.2
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
>-Original Message- >From: Ben Skeggs >Sent: Wednesday, November 11, 2020 9:39 PM >To: Ruhl, Michael J >Cc: Thomas Zimmermann ; bske...@redhat.com; >airl...@linux.ie; dan...@ffwll.ch; christian.koe...@amd.com; amd- >g...@lists.freedesktop.org; nouv...@lists.freedesktop.org; dri- >de...@lists.freedesktop.org; virtualizat...@lists.linux-foundation.org; Roland >Scheidegger ; Jason Gunthorpe ; >Huang Rui ; VMware Graphics maintai...@vmware.com>; Gerd Hoffmann ; spice- >de...@lists.freedesktop.org; Alex Deucher ; >Dave Airlie ; Likun Gao ; Felix >Kuehling ; Hawking Zhang > >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing MMU type > >On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J >wrote: >> >> >-Original Message- >> >From: Thomas Zimmermann >> >Sent: Wednesday, November 11, 2020 7:08 AM >> >To: Ruhl, Michael J ; bske...@redhat.com; >> >airl...@linux.ie; dan...@ffwll.ch; christian.koe...@amd.com >> >Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >> >Maarten Lankhorst ; Maxime Ripard >> >; Dave Airlie ; Gerd Hoffmann >> >; Alex Deucher ; >> >VMware Graphics ; Roland >> >Scheidegger ; Huang Rui ; >> >Felix Kuehling ; Hawking Zhang >> >; Jason Gunthorpe ; Likun >Gao >> >; virtualizat...@lists.linux-foundation.org; spice- >> >de...@lists.freedesktop.org; amd-...@lists.freedesktop.org >> >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when >> >deferencing MMU type >> > >> >Hi >> > >> >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: >> >> >> >> >> >>> -Original Message- >> >>> From: Thomas Zimmermann >> >>> Sent: Tuesday, November 10, 2020 8:37 AM >> >>> To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, >Michael J >> >>> ; christian.koe...@amd.com >> >>> Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >> >Thomas >> >>> Zimmermann ; Maarten Lankhorst >> >>> ; Maxime Ripard >> >>> ; Dave Airlie ; Gerd >Hoffmann >> >>> ; Alex Deucher ; >> >>> VMware Graphics ; Roland >> >>> Scheidegger ; Huang Rui >; >> >>> Felix Kuehling ; Hawking Zhang >> >>> ; Jason Gunthorpe ; Likun >> >Gao >> >>> ; virtualizat...@lists.linux-foundation.org; >spice- >> >>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org >> >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when >> >deferencing >> >>> MMU type >> >>> >> >>> The value of struct drm_device.ttm.type_vram can become -1 for >> >unknown >> >>> types of memory (see nouveau_ttm_init()). This leads to an out-of- >bounds >> >>> error when accessing struct nvif_mmu.type[]: >> >> >> >> Would this make more sense to just set the type_vram = 0 instead of -1? >> > >> >From what I understand, these indices refer to an internal type of MMU, >> >rsp the MMU's capabilities. However, my hardware (pre-NV50) does not >> >have an MMU at all. >> >> Yeah, and upon further review I see that my comment was completely >wrong >> (value vs. index). >> >> A better suggestion would have been, create an entry in the array that >means, >> "unsupported type" with a value of 0, but... >> >> >I agree that it would be nice to have a cleaner design that incorporates >> >this case, but resolving that would apparently require more than a bugfix. >> >> I agree. The -1 index is a special case for the platform path >> (platform != NV_DEVICE_INFO_V0_SOC). This is a fix for the issue, but not >> a complete solution. >> >> If you need it: >> Reviewed-by: Michael J. Ruhl >I've put an alternate fix for this here[1], and will get it into >drm-fixes later today. > >Ben. > >[1] >https://github.com/skeggsb/nouveau/commit/4590f7120c2f1f4aea9d8b93a2d >ae43b312d35ad This makes a lot of sense. I spent some time trying to reconcile the platform info that was not being used in this case, but didn't see the solution like this. This is pretty clean. If you would like: Reviewed-by: Michael J. Ruhl For this solution as well. Mike >> >> Thanks, >> Mike >> >> >Best regards >> >Thomas >> > >> >> >> >> Mike >> >> >> >>> >> >>> [
RE: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
>-Original Message- >From: Thomas Zimmermann >Sent: Wednesday, November 11, 2020 7:08 AM >To: Ruhl, Michael J ; bske...@redhat.com; >airl...@linux.ie; dan...@ffwll.ch; christian.koe...@amd.com >Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >Maarten Lankhorst ; Maxime Ripard >; Dave Airlie ; Gerd Hoffmann >; Alex Deucher ; >VMware Graphics ; Roland >Scheidegger ; Huang Rui ; >Felix Kuehling ; Hawking Zhang >; Jason Gunthorpe ; Likun Gao >; virtualizat...@lists.linux-foundation.org; spice- >de...@lists.freedesktop.org; amd-...@lists.freedesktop.org >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing MMU type > >Hi > >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: >> >> >>> -Original Message- >>> From: Thomas Zimmermann >>> Sent: Tuesday, November 10, 2020 8:37 AM >>> To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, Michael J >>> ; christian.koe...@amd.com >>> Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >Thomas >>> Zimmermann ; Maarten Lankhorst >>> ; Maxime Ripard >>> ; Dave Airlie ; Gerd Hoffmann >>> ; Alex Deucher ; >>> VMware Graphics ; Roland >>> Scheidegger ; Huang Rui ; >>> Felix Kuehling ; Hawking Zhang >>> ; Jason Gunthorpe ; Likun >Gao >>> ; virtualizat...@lists.linux-foundation.org; spice- >>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing >>> MMU type >>> >>> The value of struct drm_device.ttm.type_vram can become -1 for >unknown >>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >>> error when accessing struct nvif_mmu.type[]: >> >> Would this make more sense to just set the type_vram = 0 instead of -1? > >From what I understand, these indices refer to an internal type of MMU, >rsp the MMU's capabilities. However, my hardware (pre-NV50) does not >have an MMU at all. Yeah, and upon further review I see that my comment was completely wrong (value vs. index). A better suggestion would have been, create an entry in the array that means, "unsupported type" with a value of 0, but... >I agree that it would be nice to have a cleaner design that incorporates >this case, but resolving that would apparently require more than a bugfix. I agree. The -1 index is a special case for the platform path (platform != NV_DEVICE_INFO_V0_SOC). This is a fix for the issue, but not a complete solution. If you need it: Reviewed-by: Michael J. Ruhl Thanks, Mike >Best regards >Thomas > >> >> Mike >> >>> >>> [ 18.304116] >>> >=== >>> === >>> [ 18.311649] BUG: KASAN: slab-out-of-bounds in >>> nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] >>> [ 18.320415] Read of size 1 at addr 88810ffac1fe by task systemd- >>> udevd/342 >>> [ 18.327681] >>> [ 18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: GE >>> 5.10.0-rc2-1-default+ #581 >>> [ 18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 >>> 10/24/2018 >>> [ 18.346032] Call Trace: >>> [ 18.348536] dump_stack+0xae/0xe5 >>> [ 18.351919] print_address_description.constprop.0+0x17/0xf0 >>> [ 18.357787] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] >>> [ 18.363818] __kasan_report.cold+0x20/0x38 >>> [ 18.368099] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] >>> [ 18.374133] kasan_report+0x3a/0x50 >>> [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] >>> <...> >>> [ 18.767690] Allocated by task 342: >>> [ 18.773087] kasan_save_stack+0x1b/0x40 >>> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0 >>> [ 18.785646] __kmalloc_track_caller+0x1be/0x390 >>> [ 18.792165] kstrdup_const+0x46/0x70 >>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0 >>> [ 18.803992] kobject_init_and_add+0x9d/0xf0 >>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm] >>> [ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm] >>> [ 18.823420] ttm_bo_device_init+0x39/0x220 [ttm] >>> [ 18.830046] nouveau_ttm_init+0x2c3/0x830 [nouveau] >>> [ 18.836929] nouveau_drm_device_init+0x1b4/0x3f0 [nouveau] >>> <...> >>> [ 19.105336] >>> >===
RE: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
>-Original Message-
>From: Thomas Zimmermann
>Sent: Tuesday, November 10, 2020 8:37 AM
>To: bske...@redhat.com; airl...@linux.ie; dan...@ffwll.ch; Ruhl, Michael J
>; christian.koe...@amd.com
>Cc: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Thomas
>Zimmermann ; Maarten Lankhorst
>; Maxime Ripard
>; Dave Airlie ; Gerd Hoffmann
>; Alex Deucher ;
>VMware Graphics ; Roland
>Scheidegger ; Huang Rui ;
>Felix Kuehling ; Hawking Zhang
>; Jason Gunthorpe ; Likun Gao
>; virtualizat...@lists.linux-foundation.org; spice-
>de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing
>MMU type
>
>The value of struct drm_device.ttm.type_vram can become -1 for unknown
>types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
>error when accessing struct nvif_mmu.type[]:
Would this make more sense to just set the type_vram = 0 instead of -1?
Mike
>
> [ 18.304116]
>===
>===
> [ 18.311649] BUG: KASAN: slab-out-of-bounds in
>nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> [ 18.320415] Read of size 1 at addr 88810ffac1fe by task systemd-
>udevd/342
> [ 18.327681]
> [ 18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: GE
>5.10.0-rc2-1-default+ #581
> [ 18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
>10/24/2018
> [ 18.346032] Call Trace:
> [ 18.348536] dump_stack+0xae/0xe5
> [ 18.351919] print_address_description.constprop.0+0x17/0xf0
> [ 18.357787] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> [ 18.363818] __kasan_report.cold+0x20/0x38
> [ 18.368099] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> [ 18.374133] kasan_report+0x3a/0x50
> [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> <...>
> [ 18.767690] Allocated by task 342:
> [ 18.773087] kasan_save_stack+0x1b/0x40
> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
> [ 18.792165] kstrdup_const+0x46/0x70
> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
> [ 18.803992] kobject_init_and_add+0x9d/0xf0
> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
> [ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm]
> [ 18.823420] ttm_bo_device_init+0x39/0x220 [ttm]
> [ 18.830046] nouveau_ttm_init+0x2c3/0x830 [nouveau]
> [ 18.836929] nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
> <...>
> [ 19.105336]
>===
>===
>
>Fix this error, by not using type_vram as an index if it's negative.
>Assume default values instead.
>
>The error was seen on Nvidia G72 hardware.
>
>Signed-off-by: Thomas Zimmermann
>Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
>Cc: Christian König
>Cc: Michael J. Ruhl
>Cc: Maarten Lankhorst
>Cc: Maxime Ripard
>Cc: Thomas Zimmermann
>Cc: David Airlie
>Cc: Daniel Vetter
>Cc: Ben Skeggs
>Cc: Dave Airlie
>Cc: Gerd Hoffmann
>Cc: Alex Deucher
>Cc: "Christian König"
>Cc: VMware Graphics
>Cc: Roland Scheidegger
>Cc: Huang Rui
>Cc: Felix Kuehling
>Cc: Hawking Zhang
>Cc: Jason Gunthorpe
>Cc: Likun Gao
>Cc: dri-devel@lists.freedesktop.org
>Cc: nouv...@lists.freedesktop.org
>Cc: virtualizat...@lists.linux-foundation.org
>Cc: spice-de...@lists.freedesktop.org
>Cc: amd-...@lists.freedesktop.org
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 8133377d865d..fe15299d417e 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1142,9 +1142,12 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> struct nvkm_device *device = nvxx_device(>client.device);
> struct nouveau_mem *mem = nouveau_mem(reg);
> struct nvif_mmu *mmu = >client.mmu;
>- const u8 type = mmu->type[drm->ttm.type_vram].type;
>+ u8 type = 0;
> int ret;
>
>+ if (drm->ttm.type_vram >= 0)
>+ type = mmu->type[drm->ttm.type_vram].type;
>+
> mutex_lock(>ttm.io_reserve_mutex);
> retry:
> switch (reg->mem_type) {
>--
>2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>-Original Message-
>From: Christian König
>Sent: Wednesday, October 7, 2020 4:31 AM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org; ray.hu...@amd.com; airl...@gmail.com;
>dan...@ffwll.ch
>Subject: Re: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>
>Am 05.10.20 um 17:01 schrieb Ruhl, Michael J:
>>> -Original Message-
>>> From: dri-devel On Behalf Of
>>> Christian König
>>> Sent: Thursday, October 1, 2020 7:28 AM
>>> To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>>> airl...@gmail.com; dan...@ffwll.ch
>>> Subject: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>>>
>>> This is not something drivers should use.
>> It's not?
>
>Those are helper functions which are used by the two different page
>pools to change the global mapping of pages on x86.
>
>> I am not really sure what you are doing here.
>
>Making sure that no driver things that it should touch the CPU caching
>attributes manually :)
Got it. So should you move the header to the drivers/gpu/drm/ttm ?
Reviewed-by: Michael J. Ruhl
Mike
>Christian.
>
>>
>> M
>>
>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++-
>>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++-
>>> {include => drivers/gpu}/drm/ttm/ttm_set_memory.h | 0
>>> 3 files changed, 4 insertions(+), 2 deletions(-)
>>> rename {include => drivers/gpu}/drm/ttm/ttm_set_memory.h (100%)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>>> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>>> index 14660f723f71..912c30dcc9db 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>>> @@ -47,7 +47,8 @@
>>>
>>> #include
>>> #include
>>> -#include
>>> +
>>> +#include "ttm_set_memory.h"
>>>
>>> #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page
>>> *))
>>> #define SMALL_ALLOCATION16
>>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> index 5e2df11685e7..1045a5c26ee3 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> @@ -49,7 +49,8 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>> +
>>> +#include "ttm_set_memory.h"
>>>
>>> #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page
>>> *))
>>> #define SMALL_ALLOCATION4
>>> diff --git a/include/drm/ttm/ttm_set_memory.h
>>> b/drivers/gpu/drm/ttm/ttm_set_memory.h
>>> similarity index 100%
>>> rename from include/drm/ttm/ttm_set_memory.h
>>> rename to drivers/gpu/drm/ttm/ttm_set_memory.h
>>> --
>>> 2.17.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/ttm: remove ttm_bo_unmap_virtual_locked declaration
>-Original Message- >From: Christian König >Sent: Wednesday, October 7, 2020 4:52 AM >To: dri-devel@lists.freedesktop.org; airl...@gmail.com; >ray.hu...@amd.com; Ruhl, Michael J >Subject: [PATCH] drm/ttm: remove ttm_bo_unmap_virtual_locked >declaration > >That was missed during the cleanup. > >Signed-off-by: Christian König >--- > include/drm/ttm/ttm_bo_driver.h | 9 - > 1 file changed, 9 deletions(-) > >diff --git a/include/drm/ttm/ttm_bo_driver.h >b/include/drm/ttm/ttm_bo_driver.h >index 9897a16c0a9d..b58dedce7079 100644 >--- a/include/drm/ttm/ttm_bo_driver.h >+++ b/include/drm/ttm/ttm_bo_driver.h >@@ -449,15 +449,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev, > */ > void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo); > >-/** >- * ttm_bo_unmap_virtual >- * >- * @bo: tear down the virtual mappings for this BO >- * >- * The caller must take ttm_mem_io_lock before calling this function. >- */ >-void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo); greping for ttm_bo_unmap_virtual_locked revealed this: drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c: * This is similar to ttm_bo_unmap_virtual_locked() except it takes a subrange. include/drm/ttm/ttm_bo_driver.h:void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo); Should you clean up the vmwgvx comment to avoid confusion? Reviewed-by: Michael J. Ruhl m >- > /** > * ttm_bo_reserve: > * >-- >2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 5/8] drm/ttm: set the tt caching state at creation time
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 5/8] drm/ttm: set the tt caching state at creation time
>
>All drivers can determine the tt caching state at creation time,
>no need to do this on the fly during every validation.
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 -
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 14 +-
> drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
> drivers/gpu/drm/ttm/ttm_tt.c | 16 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
> include/drm/ttm/ttm_tt.h | 7 ---
> 9 files changed, 53 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 2af24cf39e94..7f41a47e7353 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
>ttm_bo_device *bdev,
> static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
> uint32_t page_flags)
> {
>+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
> struct amdgpu_ttm_tt *gtt;
>+ enum ttm_caching caching;
>
> gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
> if (gtt == NULL) {
>@@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
>ttm_buffer_object *bo,
> }
> gtt->gobj = >base;
>
>+ if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
>+ caching = ttm_write_combined;
>+ else
>+ caching = ttm_cached;
>+
> /* allocate space for the uninitialized page entries */
>- if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
>+ if (ttm_sg_tt_init(>ttm, bo, page_flags, caching)) {
> kfree(gtt);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 3fe4b326e18e..62235926e077 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -910,7 +910,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
>ttm_buffer_object *bo,
> if (!tt)
> return NULL;
>
>- ret = ttm_tt_init(tt, bo, page_flags);
>+ ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
> if (ret < 0)
> goto err_ttm_tt_init;
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>index 806d9ec310f5..cd6fdebae795 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>@@ -5,6 +5,7 @@
> #include "nouveau_drv.h"
> #include "nouveau_mem.h"
> #include "nouveau_ttm.h"
>+#include "nouveau_bo.h"
>
> struct nouveau_sgdma_be {
> /* this has to be the first field so populate/unpopulated in
>@@ -67,13 +68,23 @@ nouveau_sgdma_unbind(struct ttm_bo_device
>*bdev, struct ttm_tt *ttm)
> struct ttm_tt *
> nouveau_sgdma_create_ttm(struct ttm_buffer_object *bo, uint32_t
>page_flags)
> {
>+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
>+ struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_sgdma_be *nvbe;
>+ enum ttm_caching caching;
>+
>+ if (nvbo->force_coherent)
>+ caching = ttm_uncached;
>+ else if (drm->agp.bridge)
>+ caching = ttm_write_combined;
>+ else
>+ caching = ttm_cached;
>
> nvbe = kzalloc(sizeof(*nvbe), GFP_KERNEL);
> if (!nvbe)
> return NULL;
>
>- if (ttm_dma_tt_init(>ttm, bo, page_flags)) {
>+ if (ttm_dma_tt_init(>ttm, bo, page_flags, caching)) {
> kfree(nvbe);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
>index 2c35ca4270c6..dcf4ac1480c7 100644
>--- a/drivers/gpu/drm/qxl/qxl_ttm.c
>+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
>@@ -146,7 +146,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
>ttm_buffer_object *bo,
> if (gtt == NULL)
> return NULL;
> gtt->qdev = qdev;
>- if (ttm_tt_init(>ttm, bo, page_flags)) {
>+ if (ttm_tt_init(>ttm, bo, page_flags, ttm_cached)) {
> kfree(gtt);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>b/drivers/gpu/drm/radeon/radeon_ttm.c
>index f01e74113f40..130a7cea35c3 100644
>--- a/drivers/gpu/drm/radeon/radeon_ttm.c
>+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>@@ -590,6 +590,10 @@ static struct ttm_tt *radeon_ttm_tt_create(struct
>ttm_buffer_object *bo,
>
RE: [PATCH 4/8] drm/ttm: rename TTM caching enum
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 4/8] drm/ttm: rename TTM caching enum
>
>Cleanup the enum name and its values and give it a separate header file.
This clean up looks straight forward.
I am not really clear on why you are giving it a separate header. If you could
detail that a little more in the commit?
Otherwise:
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +-
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 +++---
> drivers/gpu/drm/ttm/ttm_tt.c | 17 ++--
> include/drm/ttm/ttm_caching.h| 34
> include/drm/ttm/ttm_tt.h | 9 ++-
> 8 files changed, 70 insertions(+), 42 deletions(-)
> create mode 100644 include/drm/ttm/ttm_caching.h
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>index 213ef090bb0e..3c5ad69eff19 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>@@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct
>ttm_buffer_object *bo)
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
> struct ttm_dma_tt *ttm;
>
>- if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
>+ if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> return AMDGPU_BO_INVALID_OFFSET;
>
> ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 399961035ae6..2af24cf39e94 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -1525,7 +1525,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt
>*ttm, struct ttm_resource *mem)
> if (mem && mem->mem_type == TTM_PL_TT) {
> flags |= AMDGPU_PTE_SYSTEM;
>
>- if (ttm->caching_state == tt_cached)
>+ if (ttm->caching == ttm_cached)
> flags |= AMDGPU_PTE_SNOOPED;
> }
>
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>b/drivers/gpu/drm/radeon/radeon_ttm.c
>index 63e38b05a5bc..f01e74113f40 100644
>--- a/drivers/gpu/drm/radeon/radeon_ttm.c
>+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>@@ -546,7 +546,7 @@ static int radeon_ttm_backend_bind(struct
>ttm_bo_device *bdev,
> WARN(1, "nothing to bind %lu pages for mreg %p back
>%p!\n",
>ttm->num_pages, bo_mem, ttm);
> }
>- if (ttm->caching_state == tt_cached)
>+ if (ttm->caching == ttm_cached)
> flags |= RADEON_GART_PAGE_SNOOP;
> r = radeon_gart_bind(rdev, gtt->offset, ttm->num_pages,
>ttm->pages, gtt->ttm.dma_address, flags);
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 111031cbb6df..c8f6790962b9 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -220,14 +220,14 @@ static struct ttm_pool_manager *_manager;
> /**
> * Select the right pool or requested caching state and ttm flags. */
> static struct ttm_page_pool *ttm_get_pool(int flags, bool huge,
>-enum ttm_caching_state cstate)
>+enum ttm_caching cstate)
> {
> int pool_index;
>
>- if (cstate == tt_cached)
>+ if (cstate == ttm_cached)
> return NULL;
>
>- if (cstate == tt_wc)
>+ if (cstate == ttm_write_combined)
> pool_index = 0x0;
> else
> pool_index = 0x1;
>@@ -441,17 +441,17 @@ static void ttm_pool_mm_shrink_fini(struct
>ttm_pool_manager *manager)
> }
>
> static int ttm_set_pages_caching(struct page **pages,
>- enum ttm_caching_state cstate, unsigned cpages)
>+ enum ttm_caching cstate, unsigned cpages)
> {
> int r = 0;
> /* Set page caching */
> switch (cstate) {
>- case tt_uncached:
>+ case ttm_uncached:
> r = ttm_set_pages_array_uc(pages, cpages);
> if (r)
> pr_err("Failed to set %d pages to uc!\n", cpages);
> break;
>- case tt_wc:
>+ case ttm_write_combined:
> r = ttm_set_pages_array_wc(pages, cpages);
> if (r)
> pr_err("Failed to set %d pages to wc!\n", cpages);
>@@ -486,7 +486,7 @@ static void ttm_handle_caching_failure(struct page
>**failed_pages,
> * pages returned in pages array.
> */
> static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
>-
RE: [PATCH 8/8] drm/ttm: nuke caching placement flags
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, October 1, 2020 7:28 AM >To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com; >airl...@gmail.com; dan...@ffwll.ch >Subject: [PATCH 8/8] drm/ttm: nuke caching placement flags > >Changing the caching on the fly never really worked >flawlessly. > >So stop this completely and just let drivers specific the >desired caching in the tt or bus object. > >Signed-off-by: Christian König >--- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 ++ > drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--- > drivers/gpu/drm/nouveau/nouveau_bo.c | 36 + > drivers/gpu/drm/qxl/qxl_object.c | 10 ++--- > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_object.c | 46 +- > drivers/gpu/drm/radeon/radeon_ttm.c| 18 ++--- > drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +- > drivers/gpu/drm/ttm/ttm_bo.c | 44 ++--- > drivers/gpu/drm/ttm/ttm_bo_util.c | 10 ++--- > drivers/gpu/drm/ttm/ttm_tt.c | 29 -- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 30 +++--- > include/drm/ttm/ttm_placement.h| 14 --- > include/drm/ttm/ttm_tt.h | 15 --- > 15 files changed, 61 insertions(+), 234 deletions(-) > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >index 80bc7177cd45..964f9512dd6e 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >@@ -137,7 +137,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_VRAM; >- places[c].flags = TTM_PL_FLAG_WC | >TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > > if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) > places[c].lpfn = visible_pfn; >@@ -154,11 +154,6 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_TT; > places[c].flags = 0; >- if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) >- places[c].flags |= TTM_PL_FLAG_WC | >- TTM_PL_FLAG_UNCACHED; >- else >- places[c].flags |= TTM_PL_FLAG_CACHED; > c++; > } > >@@ -167,11 +162,6 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_SYSTEM; > places[c].flags = 0; >- if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) >- places[c].flags |= TTM_PL_FLAG_WC | >- TTM_PL_FLAG_UNCACHED; >- else >- places[c].flags |= TTM_PL_FLAG_CACHED; > c++; > } > >@@ -179,7 +169,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_GDS; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -187,7 +177,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_GWS; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -195,7 +185,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_OA; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -203,7 +193,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_SYSTEM; >- places[c].flags = TTM_PL_MASK_CACHING; >+ places[c].flags = 0; > c++; > } > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >index 5b56a66063fd..8cdec58b9106 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >@@ -92,7 +92,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object >*bo, > .fpfn = 0, > .lpfn = 0, > .mem_type = TTM_PL_SYSTEM, >- .flags = TTM_PL_MASK_CACHING >+
RE: [PATCH 7/8] drm/ttm: use caching instead of placement for ttm_io_prot
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 7/8] drm/ttm: use caching instead of placement for
>ttm_io_prot
>
>Instead of the placement flags use the caching of the bus
>mapping or tt object for the page protection flags.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 23 ++-
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
> include/drm/ttm/ttm_bo_driver.h | 6 --
> 4 files changed, 21 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index bdee4df1f3f2..0542097dc419 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -279,13 +279,11 @@ int ttm_bo_move_memcpy(struct
>ttm_buffer_object *bo,
> for (i = 0; i < new_mem->num_pages; ++i) {
> page = i * dir + add;
> if (old_iomap == NULL) {
>- pgprot_t prot = ttm_io_prot(old_mem->placement,
>- PAGE_KERNEL);
So will placement get removed from ttm_resource?
Reviewed-by: Michael J. Ruhl
M
>+ pgprot_t prot = ttm_io_prot(bo, old_mem,
>PAGE_KERNEL);
> ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
> prot);
> } else if (new_iomap == NULL) {
>- pgprot_t prot = ttm_io_prot(new_mem->placement,
>- PAGE_KERNEL);
>+ pgprot_t prot = ttm_io_prot(bo, new_mem,
>PAGE_KERNEL);
> ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
> prot);
> } else {
>@@ -384,21 +382,28 @@ static int ttm_buffer_object_transfer(struct
>ttm_buffer_object *bo,
> return 0;
> }
>
>-pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>+pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource
>*res,
>+ pgprot_t tmp)
> {
>+ struct ttm_resource_manager *man;
>+ enum ttm_caching caching;
>+
>+ man = ttm_manager_type(bo->bdev, res->mem_type);
>+ caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
>+
> /* Cached mappings need no adjustment */
>- if (caching_flags & TTM_PL_FLAG_CACHED)
>+ if (caching == ttm_cached)
> return tmp;
>
> #if defined(__i386__) || defined(__x86_64__)
>- if (caching_flags & TTM_PL_FLAG_WC)
>+ if (caching == ttm_write_combined)
> tmp = pgprot_writecombine(tmp);
> else if (boot_cpu_data.x86 > 3)
> tmp = pgprot_noncached(tmp);
> #endif
> #if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \
> defined(__powerpc__) || defined(__mips__)
>- if (caching_flags & TTM_PL_FLAG_WC)
>+ if (caching == ttm_write_combined)
> tmp = pgprot_writecombine(tmp);
> else
> tmp = pgprot_noncached(tmp);
>@@ -466,7 +471,7 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object
>*bo,
>* We need to use vmap to get the desired page protection
>* or to make the buffer object look contiguous.
>*/
>- prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
>+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
> map->bo_kmap_type = ttm_bo_map_vmap;
> map->virtual = vmap(ttm->pages + start_page, num_pages,
> 0, prot);
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>index 87ee8f0ca08e..eeaca5d1efe3 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>@@ -310,7 +310,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>vm_fault *vmf,
> if (unlikely(page_offset >= bo->num_pages))
> return VM_FAULT_SIGBUS;
>
>- prot = ttm_io_prot(bo->mem.placement, prot);
>+ prot = ttm_io_prot(bo, >mem, prot);
> if (!bo->mem.bus.is_iomem) {
> struct ttm_operation_ctx ctx = {
> .interruptible = false,
>diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>index ea2f2f937eb3..f21881e087db 100644
>--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>@@ -484,8 +484,8 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
> d.src_pages = src->ttm->pages;
> d.dst_num_pages = dst->num_pages;
> d.src_num_pages = src->num_pages;
>- d.dst_prot = ttm_io_prot(dst->mem.placement, PAGE_KERNEL);
>- d.src_prot = ttm_io_prot(src->mem.placement, PAGE_KERNEL);
>+ d.dst_prot = ttm_io_prot(dst, >mem, PAGE_KERNEL);
>+
RE: [PATCH 6/8] drm/ttm: add caching state to ttm_bus_placement
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 6/8] drm/ttm: add caching state to ttm_bus_placement
>
>And implement setting it up correctly in the drivers.
>
>This allows getting rid of the placement flags for this.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
> drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
> drivers/gpu/drm/nouveau/nouveau_bo.c | 11 +++
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 ++
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
> include/drm/ttm/ttm_resource.h | 8 +---
> 7 files changed, 23 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 7f41a47e7353..5b56a66063fd 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -769,6 +769,7 @@ static int amdgpu_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_reso
>
> mem->bus.offset += adev->gmc.aper_base;
> mem->bus.is_iomem = true;
>+ mem->bus.caching = ttm_write_combined;
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 62235926e077..79151b1c157c 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -961,6 +961,7 @@ static int bo_driver_io_mem_reserve(struct
>ttm_bo_device *bdev,
> case TTM_PL_VRAM:
> mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm-
>>vram_base;
> mem->bus.is_iomem = true;
>+ mem->bus.caching = ttm_write_combined;
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 1d4b16c0e353..8ed30f471ec7 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1124,6 +1124,8 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> struct nouveau_drm *drm = nouveau_bdev(bdev);
> struct nvkm_device *device = nvxx_device(>client.device);
> struct nouveau_mem *mem = nouveau_mem(reg);
>+ struct nvif_mmu *mmu = >client.mmu;
>+ const u8 type = mmu->type[drm->ttm.type_vram].type;
> int ret;
>
> mutex_lock(>ttm.io_reserve_mutex);
>@@ -1139,6 +1141,7 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> reg->bus.offset = (reg->start << PAGE_SHIFT) +
> drm->agp.base;
> reg->bus.is_iomem = !drm->agp.cma;
Don't really know if this is true or not, so I will take your word on it.
>+ reg->bus.caching = ttm_write_combined;
> }
> #endif
> if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 ||
>@@ -1152,6 +1155,14 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> reg->bus.offset = (reg->start << PAGE_SHIFT) +
> device->func->resource_addr(device, 1);
> reg->bus.is_iomem = true;
>+
>+ /* Some BARs do not support being ioremapped WC */
>+ if (drm->client.device.info.family >=
>NV_DEVICE_INFO_V0_TESLA &&
>+ type & NVIF_MEM_UNCACHED)
>+ reg->bus.caching = ttm_uncached;
>+ else
>+ reg->bus.caching = ttm_write_combined;
>+
> if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
> union {
> struct nv50_mem_map_v0 nv50;
>diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
>index dcf4ac1480c7..e79d4df99790 100644
>--- a/drivers/gpu/drm/qxl/qxl_ttm.c
>+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
>@@ -83,11 +83,13 @@ int qxl_ttm_io_mem_reserve(struct ttm_bo_device
>*bdev,
> case TTM_PL_VRAM:
> mem->bus.is_iomem = true;
> mem->bus.offset = (mem->start << PAGE_SHIFT) + qdev-
>>vram_base;
>+ mem->bus.caching = ttm_cached;
> break;
> case TTM_PL_PRIV:
> mem->bus.is_iomem = true;
> mem->bus.offset = (mem->start << PAGE_SHIFT) +
> qdev->surfaceram_base;
>+ mem->bus.caching = ttm_cached;
is_iomem = true and ttm_cached is correct?
qxl is a software gpu?
If this is true, then this looks reasonable.
Reviewed-by: Michael J. Ruhl
M
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
RE: [PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
>
>Remove unused parameters, shorten the function name.
Looks good to me.
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 912c30dcc9db..111031cbb6df 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -467,11 +467,11 @@ static int ttm_set_pages_caching(struct page
>**pages,
> * any pages that have changed their caching state already put them to the
> * pool.
> */
>-static void ttm_handle_caching_state_failure(struct list_head *pages,
>- int ttm_flags, enum ttm_caching_state cstate,
>- struct page **failed_pages, unsigned cpages)
>+static void ttm_handle_caching_failure(struct page **failed_pages,
>+ unsigned cpages)
> {
> unsigned i;
>+
> /* Failed pages have to be freed */
> for (i = 0; i < cpages; ++i) {
> list_del(_pages[i]->lru);
>@@ -517,9 +517,8 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> r = ttm_set_pages_caching(caching_array,
> cstate, cpages);
> if (r)
>-
> ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+
> ttm_handle_caching_failure(caching_array,
>+ cpages);
> }
> r = -ENOMEM;
> goto out;
>@@ -542,9 +541,8 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> r = ttm_set_pages_caching(caching_array,
> cstate, cpages);
> if (r) {
>-
> ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+
> ttm_handle_caching_failure(caching_array,
>+ cpages);
> goto out;
> }
> cpages = 0;
>@@ -555,9 +553,7 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> if (cpages) {
> r = ttm_set_pages_caching(caching_array, cstate, cpages);
> if (r)
>- ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+ ttm_handle_caching_failure(caching_array, cpages);
> }
> out:
> kfree(caching_array);
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>
>This is not something drivers should use.
It's not?
I am not really sure what you are doing here.
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++-
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++-
> {include => drivers/gpu}/drm/ttm/ttm_set_memory.h | 0
> 3 files changed, 4 insertions(+), 2 deletions(-)
> rename {include => drivers/gpu}/drm/ttm/ttm_set_memory.h (100%)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 14660f723f71..912c30dcc9db 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -47,7 +47,8 @@
>
> #include
> #include
>-#include
>+
>+#include "ttm_set_memory.h"
>
> #define NUM_PAGES_TO_ALLOC(PAGE_SIZE/sizeof(struct page
>*))
> #define SMALL_ALLOCATION 16
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>index 5e2df11685e7..1045a5c26ee3 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>@@ -49,7 +49,8 @@
> #include
> #include
> #include
>-#include
>+
>+#include "ttm_set_memory.h"
>
> #define NUM_PAGES_TO_ALLOC(PAGE_SIZE/sizeof(struct page
>*))
> #define SMALL_ALLOCATION 4
>diff --git a/include/drm/ttm/ttm_set_memory.h
>b/drivers/gpu/drm/ttm/ttm_set_memory.h
>similarity index 100%
>rename from include/drm/ttm/ttm_set_memory.h
>rename to drivers/gpu/drm/ttm/ttm_set_memory.h
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, October 1, 2020 7:28 AM >To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com; >airl...@gmail.com; dan...@ffwll.ch >Subject: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE > >Not used any more. Reviewed-by: Michael J. Ruhl m >Signed-off-by: Christian König >--- > include/drm/ttm/ttm_tt.h | 1 - > 1 file changed, 1 deletion(-) > >diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h >index 91691240a509..5d1835d44084 100644 >--- a/include/drm/ttm/ttm_tt.h >+++ b/include/drm/ttm/ttm_tt.h >@@ -34,7 +34,6 @@ struct ttm_resource; > struct ttm_buffer_object; > struct ttm_operation_ctx; > >-#define TTM_PAGE_FLAG_WRITE (1 << 3) > #define TTM_PAGE_FLAG_SWAPPED (1 << 4) > #define TTM_PAGE_FLAG_ZERO_ALLOC (1 << 6) > #define TTM_PAGE_FLAG_DMA32 (1 << 7) >-- >2.17.1 > >___ >dri-devel mailing list >dri-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/vgem: validate vgem_device before exit operations
>-Original Message-
>From: dri-devel On Behalf Of
>Melissa Wen
>Sent: Thursday, September 17, 2020 10:22 AM
>To: Daniel Vetter ; David Airlie
>Cc: dri-devel@lists.freedesktop.org
>Subject: [PATCH] drm/vgem: validate vgem_device before exit operations
>
>This patch adds a check for the vgem_device before handling it.
>
>Signed-off-by: Melissa Wen
>---
> drivers/gpu/drm/vgem/vgem_drv.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
>b/drivers/gpu/drm/vgem/vgem_drv.c
>index cb884c890065..119ca887cb8a 100644
>--- a/drivers/gpu/drm/vgem/vgem_drv.c
>+++ b/drivers/gpu/drm/vgem/vgem_drv.c
>@@ -472,7 +472,14 @@ static int __init vgem_init(void)
>
> static void __exit vgem_exit(void)
> {
>- struct platform_device *pdev = vgem_device->platform;
>+ struct platform_device *pdev;
>+
>+ if (!vgem_device) {
>+ DRM_INFO("vgem_device is NULL\n");
>+ return;
>+ }
This only gets called on module_exit.
If module_init fails, (which is where this is allocated), will the exit ever
be called?
M
>+
>+ pdev = vgem_device->platform;
>
> drm_dev_unregister(_device->drm);
> devres_release_group(>dev, NULL);
>--
>2.28.0
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/ttm: some cleanups
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Tuesday, September 15, 2020 10:31 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH] drm/ttm: some cleanups
>
>Unexport ttm_check_under_lowerlimit.
>Make ttm_bo_acc_size static and unexport it.
>Remove ttm_get_kernel_zone_memory_size.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
> drivers/gpu/drm/ttm/ttm_memory.c | 7 ---
> include/drm/ttm/ttm_bo_api.h | 12
> include/drm/ttm/ttm_memory.h | 1 -
> 4 files changed, 3 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index ee2632128d3c..ffbdc20d8e8d 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -1254,9 +1254,9 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> }
> EXPORT_SYMBOL(ttm_bo_init);
>
>-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>- unsigned long bo_size,
>- unsigned struct_size)
>+static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>+unsigned long bo_size,
>+unsigned struct_size)
> {
> unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
> size_t size = 0;
>@@ -1266,7 +1266,6 @@ size_t ttm_bo_acc_size(struct ttm_bo_device
>*bdev,
> size += ttm_round_pot(sizeof(struct ttm_tt));
> return size;
> }
>-EXPORT_SYMBOL(ttm_bo_acc_size);
>
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
> unsigned long bo_size,
>diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>b/drivers/gpu/drm/ttm/ttm_memory.c
>index acd63b70d814..987aa32c4808 100644
>--- a/drivers/gpu/drm/ttm/ttm_memory.c
>+++ b/drivers/gpu/drm/ttm/ttm_memory.c
>@@ -554,7 +554,6 @@ ttm_check_under_lowerlimit(struct ttm_mem_global
>*glob,
>
> return false;
> }
>-EXPORT_SYMBOL(ttm_check_under_lowerlimit);
>
> static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
> struct ttm_mem_zone *single_zone,
>@@ -682,9 +681,3 @@ size_t ttm_round_pot(size_t size)
> return 0;
> }
> EXPORT_SYMBOL(ttm_round_pot);
>-
>-uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob)
>-{
>- return glob->zone_kernel->max_mem;
>-}
>-EXPORT_SYMBOL(ttm_get_kernel_zone_memory_size);
>diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>index 36ff64e2736c..fd8d29f5f370 100644
>--- a/include/drm/ttm/ttm_bo_api.h
>+++ b/include/drm/ttm/ttm_bo_api.h
>@@ -352,18 +352,6 @@ void ttm_bo_unlock_delayed_workqueue(struct
>ttm_bo_device *bdev, int resched);
> bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> const struct ttm_place *place);
>
>-/**
>- * ttm_bo_acc_size
>- *
>- * @bdev: Pointer to a ttm_bo_device struct.
>- * @bo_size: size of the buffer object in byte.
>- * @struct_size: size of the structure holding buffer object datas
>- *
>- * Returns size to account for a buffer object
>- */
>-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>- unsigned long bo_size,
>- unsigned struct_size);
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
> unsigned long bo_size,
> unsigned struct_size);
>diff --git a/include/drm/ttm/ttm_memory.h
>b/include/drm/ttm/ttm_memory.h
>index c78ea99c42cf..2d468d7c94e6 100644
>--- a/include/drm/ttm/ttm_memory.h
>+++ b/include/drm/ttm/ttm_memory.h
>@@ -91,7 +91,6 @@ extern int ttm_mem_global_alloc_page(struct
>ttm_mem_global *glob,
> extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
>struct page *page, uint64_t size);
> extern size_t ttm_round_pot(size_t size);
>-extern uint64_t ttm_get_kernel_zone_memory_size(struct
>ttm_mem_global *glob);
> extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
> uint64_t num_pages, struct ttm_operation_ctx *ctx);
^
Externs for function prototypes have always been a slight mystery to me.
Was this necessary for the EXPORT_SYMBOL?
Since this is now "local" is the extern still needed?
Regardless, I can't resist the low lying fruit...
Reviewed-by: Michael J. Ruhl
M
> #endif
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Robin Murphy
>Sent: Tuesday, September 1, 2020 3:54 PM
>To: Ruhl, Michael J ; Marek Szyprowski
>; dri-devel@lists.freedesktop.org;
>io...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org; linux-
>ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-...@lists.freedesktop.org; Christoph Hellwig
>; linux-arm-ker...@lists.infradead.org
>Subject: Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct
>sg_table related issues
>
>On 2020-09-01 20:38, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Intel-gfx On Behalf Of
>>> Marek Szyprowski
>>> Sent: Wednesday, August 26, 2020 2:33 AM
>>> To: dri-devel@lists.freedesktop.org; io...@lists.linux-foundation.org;
>>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>>> Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>>> ; intel-...@lists.freedesktop.org; Robin Murphy
>>> ; Christoph Hellwig ; linux-arm-
>>> ker...@lists.infradead.org; Marek Szyprowski
>>>
>>> Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>>> related issues
>>>
>>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>>> function
>>> returns the number of the created entries in the DMA address space.
>>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>>> dma_unmap_sg must be called with the original number of the entries
>>> passed to the dma_map_sg().
>>>
>>> struct sg_table is a common structure used for describing a non-contiguous
>>> memory buffer, used commonly in the DRM and graphics subsystems. It
>>> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>>> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>>> and DMA mapped pages (nents entry).
>>>
>>> It turned out that it was a common mistake to misuse nents and orig_nents
>>> entries, calling DMA-mapping functions with a wrong number of entries or
>>> ignoring the number of mapped entries returned by the dma_map_sg()
>>> function.
>>>
>>> This driver creatively uses sg_table->orig_nents to store the size of the
>>> allocated scatterlist and ignores the number of the entries returned by
>>> dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>>> free the (over)allocated scatterlist.
>>>
>>> This patch only introduces the common DMA-mapping wrappers operating
>>> directly on the struct sg_table objects to the dmabuf related functions,
>>> so the other drivers, which might share buffers with i915 could rely on
>>> the properly set nents and orig_nents values.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
>>> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
>>> 2 files changed, 6 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> index 2679380159fc..8a988592715b 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> @@ -48,12 +48,9 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct
>>> dma_buf_attachment *attachme
>>> src = sg_next(src);
>>> }
>>>
>>> - if (!dma_map_sg_attrs(attachment->dev,
>>> - st->sgl, st->nents, dir,
>>> - DMA_ATTR_SKIP_CPU_SYNC)) {
>>> - ret = -ENOMEM;
>>
>> You have dropped this error value.
>>
>> Do you now if this is a benign loss?
>
>True, dma_map_sgtable() will return -EINVAL rather than -ENOMEM for
>failure. A quick look through other .map_dma_buf callbacks suggests
>they're returning a motley mix of error values and NULL for failure
>cases, so I'd imagine that importers shouldn't be too sensitive to the
>exact value.
I followed some of our code through to see if anyone is checking for -ENOMEM...
I have found in some test paths... However, it is not clear to me if we can get
to those paths from here.
Anyways,
Reviewed-by: Michael J. Ruhl
Mike
>Robin.
>
>>
>> M
>>
>>> + ret = dma_map_sgtable(attachment->dev, st, dir,
>>> DMA_ATTR_SKIP_CPU_SYNC);
>>> + if (ret)
>>> goto err_free_sg;
>>> - }
>>>
>>>
RE: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Intel-gfx On Behalf Of
>Marek Szyprowski
>Sent: Wednesday, August 26, 2020 2:33 AM
>To: dri-devel@lists.freedesktop.org; io...@lists.linux-foundation.org;
>linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-...@lists.freedesktop.org; Robin Murphy
>; Christoph Hellwig ; linux-arm-
>ker...@lists.infradead.org; Marek Szyprowski
>
>Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>related issues
>
>The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>function
>returns the number of the created entries in the DMA address space.
>However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>dma_unmap_sg must be called with the original number of the entries
>passed to the dma_map_sg().
>
>struct sg_table is a common structure used for describing a non-contiguous
>memory buffer, used commonly in the DRM and graphics subsystems. It
>consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>and DMA mapped pages (nents entry).
>
>It turned out that it was a common mistake to misuse nents and orig_nents
>entries, calling DMA-mapping functions with a wrong number of entries or
>ignoring the number of mapped entries returned by the dma_map_sg()
>function.
>
>This driver creatively uses sg_table->orig_nents to store the size of the
>allocated scatterlist and ignores the number of the entries returned by
>dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>free the (over)allocated scatterlist.
>
>This patch only introduces the common DMA-mapping wrappers operating
>directly on the struct sg_table objects to the dmabuf related functions,
>so the other drivers, which might share buffers with i915 could rely on
>the properly set nents and orig_nents values.
>
>Signed-off-by: Marek Szyprowski
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 2679380159fc..8a988592715b 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> src = sg_next(src);
> }
>
>- if (!dma_map_sg_attrs(attachment->dev,
>-st->sgl, st->nents, dir,
>-DMA_ATTR_SKIP_CPU_SYNC)) {
>- ret = -ENOMEM;
You have dropped this error value.
Do you now if this is a benign loss?
M
>+ ret = dma_map_sgtable(attachment->dev, st, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
>+ if (ret)
> goto err_free_sg;
>- }
>
> return st;
>
>@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
>>dmabuf);
>
>- dma_unmap_sg_attrs(attachment->dev,
>- sg->sgl, sg->nents, dir,
>- DMA_ATTR_SKIP_CPU_SYNC);
>+ dma_unmap_sgtable(attachment->dev, sg, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
>
>diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>index debaf7b18ab5..be30b27e2926 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
>dma_buf_attachment *attachment,
> sg = sg_next(sg);
> }
>
>- if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
>- err = -ENOMEM;
>+ err = dma_map_sgtable(attachment->dev, st, dir, 0);
>+ if (err)
> goto err_st;
>- }
>
> return st;
>
>@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> struct sg_table *st,
> enum dma_data_direction dir)
> {
>- dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
>+ dma_unmap_sgtable(attachment->dev, st, dir, 0);
> sg_free_table(st);
> kfree(st);
> }
>--
>2.17.1
>
>___
>Intel-gfx mailing list
>intel-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/dp_mst: Don't return error code when crtc is null
>-Original Message- >From: dri-devel On Behalf Of >Bhawanpreet Lakha >Sent: Friday, August 14, 2020 1:02 PM >To: mikita.lip...@amd.com; nicholas.kazlaus...@amd.com; >alexander.deuc...@amd.com >Cc: Bhawanpreet Lakha ; dri- >de...@lists.freedesktop.org; amd-...@lists.freedesktop.org >Subject: [PATCH] drm/dp_mst: Don't return error code when crtc is null > >[Why] >In certain cases the crtc can be NULL and returning -EINVAL causes >atomic check to fail when it shouln't. This leads to valid >configurations failing because atomic check fails. So is this a bug fix or an exception case, or an expected possibility? >From my reading of the function comments, it is not clear that >pos->port->connector might be NULL for some reason. A better explanation of why this would occur would make this a much more useful commit message. My reading is that you ran into this issue an are masking it with this fix. Rather than this is a real possibility and this is the correct fix. Mike >[How] >Don't early return if crtc is null > >Signed-off-by: Bhawanpreet Lakha >--- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c >b/drivers/gpu/drm/drm_dp_mst_topology.c >index 70c4b7afed12..bc90a1485699 100644 >--- a/drivers/gpu/drm/drm_dp_mst_topology.c >+++ b/drivers/gpu/drm/drm_dp_mst_topology.c >@@ -5037,8 +5037,8 @@ int drm_dp_mst_add_affected_dsc_crtcs(struct >drm_atomic_state *state, struct drm > > crtc = conn_state->crtc; > >- if (WARN_ON(!crtc)) >- return -EINVAL; >+ if (!crtc) >+ continue; > > if (!drm_dp_mst_dsc_aux_for_port(pos->port)) > continue; >-- >2.17.1 > >___ >dri-devel mailing list >dri-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>-Original Message-
>From: Ben Skeggs
>Sent: Tuesday, July 28, 2020 4:16 PM
>To: Ruhl, Michael J
>Cc: Dave Airlie ; dri-devel@lists.freedesktop.org;
>bske...@redhat.com
>Subject: Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J
>wrote:
>>
>> >-Original Message-
>> >From: dri-devel On Behalf Of
>> >Dave Airlie
>> >Sent: Monday, July 27, 2020 11:26 PM
>> >To: dri-devel@lists.freedesktop.org
>> >Cc: bske...@redhat.com
>> >Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>> >
>> >From: Dave Airlie
>> >
>> >Instead of rolling driver copies of them.
>> >
>> >v2: cleanup return handling (Ben)
>> >Signed-off-by: Dave Airlie
>> >---
>> > drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++--
>> > 1 file changed, 2 insertions(+), 36 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >index 7806278dce57..6ef5085c9a91 100644
>> >--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> >@@ -1231,8 +1231,6 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>> >struct ttm_operation_ctx *ctx)
>> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
>> > struct nouveau_drm *drm;
>> > struct device *dev;
>> >- unsigned i;
>> >- int r;
>> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>> >
>> > if (ttm->state != tt_unpopulated)
>> >@@ -1260,31 +1258,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>> >struct ttm_operation_ctx *ctx)
>> > return ttm_dma_populate((void *)ttm, dev, ctx);
>> > }
>> > #endif
>> >-
>> >- r = ttm_pool_populate(ttm, ctx);
>> >- if (r) {
>> >- return r;
>> >- }
>> >-
>> >- for (i = 0; i < ttm->num_pages; i++) {
>> >- dma_addr_t addr;
>> >-
>> >- addr = dma_map_page(dev, ttm->pages[i], 0, PAGE_SIZE,
>> >- DMA_BIDIRECTIONAL);
>> >-
>> >- if (dma_mapping_error(dev, addr)) {
>> >- while (i--) {
>> >- dma_unmap_page(dev, ttm_dma-
>> >>dma_address[i],
>> >- PAGE_SIZE,
>> >DMA_BIDIRECTIONAL);
>> >- ttm_dma->dma_address[i] = 0;
>> >- }
>> >- ttm_pool_unpopulate(ttm);
>> >- return -EFAULT;
>> >- }
>> >-
>> >- ttm_dma->dma_address[i] = addr;
>> >- }
>> >- return 0;
>> >+ return ttm_populate_and_map_pages(dev, ttm_dma, ctx);
>>
>> This is not a completely straight code replacement.
>>
>> ttm_populate_and_map_pages() also has code to deal with pages that are
>> contiguous (consolidates them).
>>
>> Is it possible that the nouveau HW can't handle a contiguous buffer larger
>> than PAG_SIZE?
>I think it's fine. The function appears to consolidate the pages for
>the dma_map_page() call, but otherwise leave dma_address[] in
>PAGE_SIZE chunks, I don't believe anything else in the driver will
>care.
Ahh.. I misread it. This is limiting the calls to dma_map_page(). Instead
of calling it for each page, just do it for the first one...
Thanks for setting me straight.
Reviewed-by: Michael J. Ruhl
Mike
>Ben.
>
>>
>> Thanks,
>>
>> Mike
>>
>> > }
>> >
>> > static void
>> >@@ -1293,7 +1267,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>> > struct ttm_dma_tt *ttm_dma = (void *)ttm;
>> > struct nouveau_drm *drm;
>> > struct device *dev;
>> >- unsigned i;
>> > bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>> >
>> > if (slave)
>> >@@ -1316,14 +1289,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt
>*ttm)
>> > }
>> > #endif
>> >
>> >- for (i = 0; i < ttm->num_pages; i++) {
>> >- if (ttm_dma->dma_address[i]) {
>> >- dma_unmap_page(dev, ttm_dma->dma_address[i],
>> >PAGE_SIZE,
>> >- DMA_BIDIRECTIONAL);
>> >- }
>> >- }
>> >-
>> >- ttm_pool_unpopulate(ttm);
>> >+ ttm_unmap_and_unpopulate_pages(dev, ttm_dma);
>> > }
>> >
>> > void
>> >--
>> >2.26.2
>> >
>> >___
>> >dri-devel mailing list
>> >dri-devel@lists.freedesktop.org
>> >https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>-Original Message-
>From: dri-devel On Behalf Of
>Dave Airlie
>Sent: Monday, July 27, 2020 11:26 PM
>To: dri-devel@lists.freedesktop.org
>Cc: bske...@redhat.com
>Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>From: Dave Airlie
>
>Instead of rolling driver copies of them.
>
>v2: cleanup return handling (Ben)
>Signed-off-by: Dave Airlie
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++--
> 1 file changed, 2 insertions(+), 36 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 7806278dce57..6ef5085c9a91 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1231,8 +1231,6 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>struct ttm_operation_ctx *ctx)
> struct ttm_dma_tt *ttm_dma = (void *)ttm;
> struct nouveau_drm *drm;
> struct device *dev;
>- unsigned i;
>- int r;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (ttm->state != tt_unpopulated)
>@@ -1260,31 +1258,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm,
>struct ttm_operation_ctx *ctx)
> return ttm_dma_populate((void *)ttm, dev, ctx);
> }
> #endif
>-
>- r = ttm_pool_populate(ttm, ctx);
>- if (r) {
>- return r;
>- }
>-
>- for (i = 0; i < ttm->num_pages; i++) {
>- dma_addr_t addr;
>-
>- addr = dma_map_page(dev, ttm->pages[i], 0, PAGE_SIZE,
>- DMA_BIDIRECTIONAL);
>-
>- if (dma_mapping_error(dev, addr)) {
>- while (i--) {
>- dma_unmap_page(dev, ttm_dma-
>>dma_address[i],
>- PAGE_SIZE,
>DMA_BIDIRECTIONAL);
>- ttm_dma->dma_address[i] = 0;
>- }
>- ttm_pool_unpopulate(ttm);
>- return -EFAULT;
>- }
>-
>- ttm_dma->dma_address[i] = addr;
>- }
>- return 0;
>+ return ttm_populate_and_map_pages(dev, ttm_dma, ctx);
This is not a completely straight code replacement.
ttm_populate_and_map_pages() also has code to deal with pages that are
contiguous (consolidates them).
Is it possible that the nouveau HW can't handle a contiguous buffer larger
than PAG_SIZE?
Thanks,
Mike
> }
>
> static void
>@@ -1293,7 +1267,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> struct ttm_dma_tt *ttm_dma = (void *)ttm;
> struct nouveau_drm *drm;
> struct device *dev;
>- unsigned i;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (slave)
>@@ -1316,14 +1289,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> }
> #endif
>
>- for (i = 0; i < ttm->num_pages; i++) {
>- if (ttm_dma->dma_address[i]) {
>- dma_unmap_page(dev, ttm_dma->dma_address[i],
>PAGE_SIZE,
>- DMA_BIDIRECTIONAL);
>- }
>- }
>-
>- ttm_pool_unpopulate(ttm);
>+ ttm_unmap_and_unpopulate_pages(dev, ttm_dma);
> }
>
> void
>--
>2.26.2
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] io-mapping: Indicate mapping failure
>-Original Message-
>From: Andrew Morton
>Sent: Tuesday, July 21, 2020 5:24 PM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport ;
>Andy Shevchenko ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
> wrote:
>
>> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>> >+++ a/include/linux/io-mapping.h
>> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
>> > resource_size_t base,
>> > unsigned long size)
>> > {
>> >+ iomap->iomem = ioremap_wc(base, size);
>> >+ if (!iomap->iomem)
>> >+ return NULL;
>> >+
>>
>> This does make more sense.
>>
>> I am confused by the two follow up emails I just got.
>
>One was your original patch, the other is my suggested alteration.
>
>> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
>> now in the tree.
>
>All is OK. If my alteration is acceptable (and, preferably, tested!)
>then when the time comes, I'll fold it into the base patch, add a
>note indicating this change and shall then send it to Linus.
I am good with the change and have tested it.
Instead of the system crashing I get:
i915 :01:00.0: [drm] *ERROR* Failed to setup region(-5) type=1
i915 :01:00.0: Device initialization failed (-5)
i915: probe of :01:00.0 failed with error -5
Which is the expected error.
If you would like this for the updated patch:
Tested-By: Michael J. Ruhl
Thanks!
Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] io-mapping: Indicate mapping failure
>-Original Message-
>From: Andrew Morton
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport ;
>Andy Shevchenko ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
> wrote:
>
>> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
>> success, even when the ioremap fails.
>>
>> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
>> callers check for a NULL return on error this is unexpected.
>>
>> During a device probe, where the ioremap failed, a crash can look
>> like this:
>>
>> BUG: unable to handle page fault for address: 0021
>> #PF: supervisor write access in kernel mode
>> #PF: error_code(0x0002) - not-present page
>> Oops: 0002 [#1] PREEMPT SMP
>> CPU: 0 PID: 177 Comm:
>> RIP: 0010:fill_page_dma [i915]
>> gen8_ppgtt_create [i915]
>> i915_ppgtt_create [i915]
>> intel_gt_init [i915]
>> i915_gem_init [i915]
>> i915_driver_probe [i915]
>> pci_device_probe
>> really_probe
>> driver_probe_device
>>
>> The remap failure occurred much earlier in the probe. If it had
>> been propagated, the driver would have exited with an error.
>>
>> Return NULL on ioremap failure.
>>
>> ...
>>
>> --- a/include/linux/io-mapping.h
>> +++ b/include/linux/io-mapping.h
>> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>> iomap->prot = pgprot_noncached(PAGE_KERNEL);
>> #endif
>>
>> -return iomap;
>> +return iomap->iomem ? iomap : NULL;
>> }
>>
>> static inline void
>
>LGTM. However I do think it would be stylistically better/typical to
>detect and handle the error early, rather than to blunder on,
>pointlessly initializing things?
Yeah, I pondered that, and then didn't do it...
>--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>+++ a/include/linux/io-mapping.h
>@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> resource_size_t base,
> unsigned long size)
> {
>+ iomap->iomem = ioremap_wc(base, size);
>+ if (!iomap->iomem)
>+ return NULL;
>+
This does make more sense.
I am confused by the two follow up emails I just got.
Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
now in the tree.
Thanks,
Mike
> iomap->base = base;
> iomap->size = size;
>- iomap->iomem = ioremap_wc(base, size);
> #if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
> iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
> #elif defined(pgprot_writecombine)
>@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
> iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
>- return iomap->iomem ? iomap : NULL;
>+ return iomap;
> }
>
> static inline void
>_
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] io-mapping: Indicate mapping failure
>-Original Message-
>From: Andy Shevchenko
>Sent: Tuesday, July 21, 2020 10:47 AM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Andrew Morton foundation.org>; Mike Rapoport ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH] io-mapping: Indicate mapping failure
>
>On Tue, Jul 21, 2020 at 10:16:41AM -0400, Michael J. Ruhl wrote:
>> Sometimes it is good to know when your mapping failed.
>
>Can you elaborate...
Sure, guess I was too glib.
Currently the io_mapping_init_wc (the !ATOMIC_IOMAP version), function will
always return success.
If the setting of the iomem (from ioremap_wc) fails, the only way for the
caller to know is to check the value of iomap->iomem.
Since all of the callers expect a NULL return on error, and check for a NULL,
I felt this needed a fixes (i.e. unexpected behavior).
>> Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata
>about the io-mapping"
>
>...especially taking into account that Fixes implies regression / bug?
The failure (in my case a crash) is not revealed until the address is accessed
long after the init.
I will update the commit.
Mike
>--
>With Best Regards,
>Andy Shevchenko
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v8 2/5] driver core: add deferring probe reason to devices_deferred property
>-Original Message-
>From: dri-devel On Behalf Of
>Andrzej Hajda
>Sent: Friday, July 10, 2020 11:30 AM
>To: Greg Kroah-Hartman
>Cc: Jernej Skrabec ; Rafael J. Wysocki
>; Jonas Karlman ; Bartlomiej
>Zolnierkiewicz ; linux-ker...@vger.kernel.org;
>open list:DRM DRIVERS ; Russell King - ARM
>Linux ; Neil Armstrong ;
>Andrzej Hajda ; andy.shevche...@gmail.com; Mark
>Brown ; Laurent Pinchart
>; linux-arm-
>ker...@lists.infradead.org; Marek Szyprowski
>
>Subject: [PATCH v8 2/5] driver core: add deferring probe reason to
>devices_deferred property
>
>/sys/kernel/debug/devices_deferred property contains list of deferred
>devices.
>This list does not contain reason why the driver deferred probe, the patch
>improves it.
>The natural place to set the reason is dev_err_probe function introduced
>recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
>printk the message will be attached to a deferred device and printed when
>user
>reads devices_deferred property.
>
>Signed-off-by: Andrzej Hajda
>Reviewed-by: Mark Brown
>Reviewed-by: Javier Martinez Canillas
>Reviewed-by: Andy Shevchenko
>Reviewed-by: Rafael J. Wysocki
>---
>v8:
>- improved commit message
>---
> drivers/base/base.h | 3 +++
> drivers/base/core.c | 8 ++--
> drivers/base/dd.c | 23 ++-
> 3 files changed, 31 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/base/base.h b/drivers/base/base.h
>index 95c22c0f9036..6954fccab3d7 100644
>--- a/drivers/base/base.h
>+++ b/drivers/base/base.h
>@@ -93,6 +93,7 @@ struct device_private {
> struct klist_node knode_class;
> struct list_head deferred_probe;
> struct device_driver *async_driver;
>+ char *deferred_probe_reason;
> struct device *device;
> u8 dead:1;
> };
>@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct
>device *dev,
> extern void driver_detach(struct device_driver *drv);
> extern int driver_probe_device(struct device_driver *drv, struct device
>*dev);
> extern void driver_deferred_probe_del(struct device *dev);
>+extern void device_set_deferred_probe_reson(const struct device *dev,
>+ struct va_format *vaf);
> static inline int driver_match_device(struct device_driver *drv,
> struct device *dev)
> {
>diff --git a/drivers/base/core.c b/drivers/base/core.c
>index 3a827c82933f..fee047f03681 100644
>--- a/drivers/base/core.c
>+++ b/drivers/base/core.c
>@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
> * This helper implements common pattern present in probe functions for
>error
> * checking: print debug or error message depending if the error value is
> * -EPROBE_DEFER and propagate error upwards.
>+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
>+ * checked later by reading devices_deferred debugfs attribute.
> * It replaces code sequence:
> *if (err != -EPROBE_DEFER)
> *dev_err(dev, ...);
>@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int
>err, const char *fmt, ...)
> vaf.fmt = fmt;
> vaf.va =
>
>- if (err != -EPROBE_DEFER)
>+ if (err != -EPROBE_DEFER) {
> dev_err(dev, "error %d: %pV", err, );
>- else
>+ } else {
>+ device_set_deferred_probe_reson(dev, );
> dev_dbg(dev, "error %d: %pV", err, );
>+ }
>
> va_end(args);
>
>diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>index 9a1d940342ac..dd5683b61f74 100644
>--- a/drivers/base/dd.c
>+++ b/drivers/base/dd.c
>@@ -27,6 +27,7 @@
> #include
> #include
> #include
>+#include
>
> #include "base.h"
> #include "power/power.h"
>@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
> if (!list_empty(>p->deferred_probe)) {
> dev_dbg(dev, "Removed from deferred list\n");
> list_del_init(>p->deferred_probe);
>+ kfree(dev->p->deferred_probe_reason);
>+ dev->p->deferred_probe_reason = NULL;
> }
> mutex_unlock(_probe_mutex);
> }
>@@ -211,6 +214,23 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
>+/**
>+ * device_set_deferred_probe_reson() - Set defer probe reason message
>for device
>+ * @dev: the pointer to the struct device
>+ * @vaf: the pointer to va_format structure with message
>+ */
>+void device_set_deferred_probe_reson(const struct device *dev, struct
Is 'reson' supposed to be 'reason'?
Same spelling on the above kernel-doc, but the comment says "reason".
mike
>va_format *vaf)
>+{
>+ const char *drv = dev_driver_string(dev);
>+
>+ mutex_lock(_probe_mutex);
>+
>+ kfree(dev->p->deferred_probe_reason);
>+ dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s:
>%pV", drv, vaf);
>+
>+ mutex_unlock(_probe_mutex);
>+}
>+
> /*
> * deferred_devs_show() - Show the devices in the deferred probe pending
>list.
> */
>@@ -221,7 +241,8 @@ static
RE: [PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v3
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 11:19 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v3
>
>Instead of signaling failure by setting the node pointer to
>NULL do so by returning -ENOSPC.
>
>v2: add memset() to make sure that mem is always initialized.
>v3: drop memset() only set mm_node = NULL, move mm_node init in amdgpu
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
> 6 files changed, 12 insertions(+), 23 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>index 627104401e84..2c20d23d62d1 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
> atomic64_read(>available) < mem->num_pages) {
> spin_unlock(>lock);
>- return 0;
>+ return -ENOSPC;
> }
> atomic64_sub(mem->num_pages, >available);
> spin_unlock(>lock);
>@@ -250,7 +250,6 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if (unlikely(r)) {
> kfree(node);
> mem->mm_node = NULL;
>- r = 0;
> goto err_out;
> }
> } else {
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 128a667ed8fa..e8d1dd564006 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> atomic64_sub(mem_bytes, >usage);
>- mem->mm_node = NULL;
>- return 0;
>+ return -ENOSPC;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>
> kvfree(nodes);
>- return r == -ENOSPC ? 0 : r;
>+ return r;
> }
>
> /**
>diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>index 7ca0a2498532..e89ea052cf71 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct
>ttm_mem_type_manager *man,
> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct
>ttm_mem_type_manager *man,
> reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index f78cfc76ad78..2da8dbd2553b 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
>ttm_buffer_object *bo,
> ticket = dma_resv_locking_ctx(bo->base.resv);
> do {
> ret = (*man->func->get_node)(man, bo, place, mem);
>- if (unlikely(ret != 0))
>- return ret;
>- if (mem->mm_node)
>+ if (likely(!ret))
> break;
>+ if (unlikely(ret != -ENOSPC))
>+ return ret;
> ret = ttm_mem_evict_first(bdev, mem->mem_type, place,
>ctx,
> ticket);
> if (unlikely(ret != 0))
>@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object
>*bo,
>
> man = >man[mem->mem_type];
> ret = (*man->func->get_node)(man, bo, place, mem);
>+ if (ret == -ENOSPC)
>+ continue;
> if (unlikely(ret))
> goto error;
>
>- if (!mem->mm_node)
>-
RE: [PATCH 2/2] drm/ttm: make TT creation purely optional v2
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/ttm: make TT creation purely optional v2
>
>We only need the page array when the BO is about to be accessed.
>
>So not only populate, but also create it on demand.
>
>v2: move NULL check into ttm_tt_create()
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 37 ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 9 ++--
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 +
> drivers/gpu/drm/ttm/ttm_tt.c | 4 +++-
> 4 files changed, 24 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 06b8bc0d8f23..c8c25e45751a 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -292,12 +292,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>*/
>
> if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
>- if (bo->ttm == NULL) {
>- bool zero = !(old_man->flags &
>TTM_MEMTYPE_FLAG_FIXED);
>- ret = ttm_tt_create(bo, zero);
>- if (ret)
>- goto out_err;
>- }
>+ bool zero = !(old_man->flags &
>TTM_MEMTYPE_FLAG_FIXED);
>+
>+ ret = ttm_tt_create(bo, zero);
>+ if (ret)
>+ goto out_err;
>
> ret = ttm_tt_set_placement_caching(bo->ttm, mem-
>>placement);
> if (ret)
>@@ -660,13 +659,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> placement.num_busy_placement = 0;
> bdev->driver->evict_flags(bo, );
>
>- if (!placement.num_placement &&
>!placement.num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement.num_placement &&
>!placement.num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
>@@ -1194,13 +1188,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Remove the backing store if no placement is given.
>*/
>- if (!placement->num_placement && !placement-
>>num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement->num_placement && !placement-
>>num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> /*
>* Check whether we need to move buffer.
>@@ -1217,14 +1206,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> ttm_flag_masked(>mem.placement, new_flags,
> ~TTM_PL_MASK_MEMTYPE);
> }
>- /*
>- * We might need to add a TTM.
>- */
>- if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>- ret = ttm_tt_create(bo, true);
>- if (ret)
>- return ret;
>- }
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_validate);
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 52d2b71f1588..f8414f820350 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -580,12 +580,17 @@ static int ttm_bo_kmap_ttm(struct
>ttm_buffer_object *bo,
> .interruptible = false,
> .no_wait_gpu = false
> };
>- struct ttm_tt *ttm = bo->ttm;
>+ struct ttm_tt *ttm;
> pgprot_t prot;
> int ret;
>
>- BUG_ON(!ttm);
>+ if (!bo->ttm) {
>+ ret = ttm_tt_create(bo, true);
>+ if (ret)
>+ return ret;
>+ }
I think that this chunk can be reduced to:
ret = ttm_tt_create(bo, true);
if (ret)
return ret;
?
With that change (unless I missed something here?):
Reviewed-by: Michael J. Ruhl
Mike
>
>+ ttm = bo->ttm;
> ret = ttm_tt_populate(ttm, );
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>index 0ad30b112982..0586870ab642 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>@@ -349,6 +349,11 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>vm_fault *vmf,
>
> };
>
>+ if (ttm_tt_create(bo, true)) {
>+ ret = VM_FAULT_OOM;
>+ goto out_io_unlock;
>+ }
>+
> ttm = bo->ttm;
> if (ttm_tt_populate(bo->ttm, )) {
> ret = VM_FAULT_OOM;
>diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>index 2ec448e1d663..e25d4097aa16 100644
>---
RE: [PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v2
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v2
>
>Instead of signaling failure by setting the node pointer to
>NULL do so by returning -ENOSPC.
>
>v2: add memset() to make sure that mem is always initialized.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
> 6 files changed, 11 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>index 627104401e84..2baa80224fa4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
> atomic64_read(>available) < mem->num_pages) {
> spin_unlock(>lock);
>- return 0;
>+ return -ENOSPC;
> }
> atomic64_sub(mem->num_pages, >available);
> spin_unlock(>lock);
>@@ -249,8 +249,6 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
> if (unlikely(r)) {
> kfree(node);
>- mem->mm_node = NULL;
>- r = 0;
I think that this one is still a problem. The code path sets:
mem->mm_node = node;
(about 3 lines above this chunk, and then calls
amdgpu_gtt_mgr_malloc()
If amdgpu_gtt_mgr_malloc() fails, mm_node is still set. I think you need to
keep
this mm_node = NULL setting, or the path needs to be modified to not set
mm_node.
> goto err_out;
> }
> } else {
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 128a667ed8fa..e8d1dd564006 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> atomic64_sub(mem_bytes, >usage);
>- mem->mm_node = NULL;
>- return 0;
>+ return -ENOSPC;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>
> kvfree(nodes);
>- return r == -ENOSPC ? 0 : r;
>+ return r;
> }
>
> /**
>diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>index 7ca0a2498532..e89ea052cf71 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct
>ttm_mem_type_manager *man,
> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct
>ttm_mem_type_manager *man,
> reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index f78cfc76ad78..06b8bc0d8f23 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
>ttm_buffer_object *bo,
> ticket = dma_resv_locking_ctx(bo->base.resv);
> do {
> ret = (*man->func->get_node)(man, bo, place, mem);
>- if (unlikely(ret != 0))
>- return ret;
>- if (mem->mm_node)
>+ if (likely(!ret))
> break;
>+ if (unlikely(ret != -ENOSPC))
>+ return ret;
> ret = ttm_mem_evict_first(bdev, mem->mem_type, place,
>ctx,
> ticket);
> if (unlikely(ret != 0))
>@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object
>*bo,
>
>
RE: [PATCH 2/2] drm/ttm: make TT creation purely optional
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Wednesday, June 24, 2020 9:36 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/ttm: make TT creation purely optional
>
>We only need the page array when the BO is about to be accessed.
>
>So not only populate, but also create it on demand.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 26 --
> drivers/gpu/drm/ttm/ttm_bo_util.c | 9 +++--
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 +
> 3 files changed, 16 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 15f9b19fa00d..0e0a9dadf3ed 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -667,13 +667,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> placement.num_busy_placement = 0;
> bdev->driver->evict_flags(bo, );
>
>- if (!placement.num_placement &&
>!placement.num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement.num_placement &&
>!placement.num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
>@@ -1200,13 +1195,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Remove the backing store if no placement is given.
>*/
>- if (!placement->num_placement && !placement-
>>num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement->num_placement && !placement-
>>num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> /*
>* Check whether we need to move buffer.
>@@ -1223,14 +1213,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> ttm_flag_masked(>mem.placement, new_flags,
> ~TTM_PL_MASK_MEMTYPE);
> }
>- /*
>- * We might need to add a TTM.
>- */
>- if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>- ret = ttm_tt_create(bo, true);
>- if (ret)
>- return ret;
>- }
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_validate);
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 52d2b71f1588..f8414f820350 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -580,12 +580,17 @@ static int ttm_bo_kmap_ttm(struct
>ttm_buffer_object *bo,
> .interruptible = false,
> .no_wait_gpu = false
> };
>- struct ttm_tt *ttm = bo->ttm;
>+ struct ttm_tt *ttm;
> pgprot_t prot;
> int ret;
>
>- BUG_ON(!ttm);
>+ if (!bo->ttm) {
>+ ret = ttm_tt_create(bo, true);
Would it be reasonable to move the NULL check into ttm_tt_create()?
Kind of an opposite path NULL check, but it makes the path a little
more clean.
Mike
>+ if (ret)
>+ return ret;
>+ }
>
>+ ttm = bo->ttm;
> ret = ttm_tt_populate(ttm, );
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>index 0ad30b112982..bdfed6725d6f 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>@@ -349,6 +349,11 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>vm_fault *vmf,
>
> };
>
>+ if (!bo->ttm && ttm_tt_create(bo, true)) {
>+ ret = VM_FAULT_OOM;
>+ goto out_io_unlock;
>+ }
>+
> ttm = bo->ttm;
> if (ttm_tt_populate(bo->ttm, )) {
> ret = VM_FAULT_OOM;
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Wednesday, June 24, 2020 9:36 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface
>
>Instead of signaling failure by setting the node pointer to
>NULL do so by returning -ENOSPC.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
> 6 files changed, 10 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>index 627104401e84..2baa80224fa4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
> atomic64_read(>available) < mem->num_pages) {
> spin_unlock(>lock);
>- return 0;
>+ return -ENOSPC;
> }
> atomic64_sub(mem->num_pages, >available);
> spin_unlock(>lock);
>@@ -249,8 +249,6 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
> if (unlikely(r)) {
> kfree(node);
>- mem->mm_node = NULL;
Hmm, amdgpu_gtt_mgr_del() grabs mem->mm_node and kfrees it.
If this value is not NUL, it looks like bad things could happen.
Will _mgr_del never get called in this case?
Using the return value seems pretty reasonable, leaving bad pointers
lying around makes me slightly nervous.
Mike
>- r = 0;
> goto err_out;
> }
> } else {
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 128a667ed8fa..e8d1dd564006 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> atomic64_sub(mem_bytes, >usage);
>- mem->mm_node = NULL;
>- return 0;
>+ return -ENOSPC;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>
> kvfree(nodes);
>- return r == -ENOSPC ? 0 : r;
>+ return r;
> }
>
> /**
>diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>index 7ca0a2498532..e89ea052cf71 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct
>ttm_mem_type_manager *man,
> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct
>ttm_mem_type_manager *man,
> reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index f73b81c2576e..15f9b19fa00d 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -916,10 +916,10 @@ static int ttm_bo_mem_force_space(struct
>ttm_buffer_object *bo,
> ticket = dma_resv_locking_ctx(bo->base.resv);
> do {
> ret = (*man->func->get_node)(man, bo, place, mem);
>- if (unlikely(ret != 0))
>- return ret;
>- if (mem->mm_node)
>+ if (likely(!ret))
> break;
>+ if (unlikely(ret != -ENOSPC))
>+ return ret;
> ret = ttm_mem_evict_first(bdev, mem->mem_type, place,
>ctx,
> ticket);
> if (unlikely(ret != 0))
>@@ -1063,12 +1063,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object
>*bo,
>
> man = >man[mem->mem_type];
> ret = (*man->func->get_node)(man, bo, place, mem);
>+
RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan Teja >Kalla >Sent: Tuesday, June 23, 2020 7:34 AM >To: Ruhl, Michael J ; Sumit Semwal >; david.lai...@aculab.com; open list:DMA >BUFFER SHARING FRAMEWORK ; DRI mailing >list >Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org> >Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name > >Thanks Mike for the inputs. > >On 6/22/2020 5:10 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: charante=codeaurora@mg.codeaurora.org >>> On Behalf Of Charan >Teja >>> Kalla >>> Sent: Monday, June 22, 2020 5:26 AM >>> To: Ruhl, Michael J ; Sumit Semwal >>> ; david.lai...@aculab.com; open list:DMA >>> BUFFER SHARING FRAMEWORK ; DRI >mailing >>> list >>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org> >>> Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name >>> >>> Hello Mike, >>> >>> On 6/19/2020 7:11 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: charante=codeaurora@mg.codeaurora.org >>>>> On Behalf Of Charan >>> Teja >>>>> Kalla >>>>> Sent: Friday, June 19, 2020 7:57 AM >>>>> To: Sumit Semwal ; Ruhl, Michael J >>>>> ; david.lai...@aculab.com; open >list:DMA >>>>> BUFFER SHARING FRAMEWORK ; DRI >>> mailing >>>>> list >>>>> Cc: Linaro MM SIG ; LKML >>>> ker...@vger.kernel.org> >>>>> Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name >>>>> >>>>> There exists a sleep-while-atomic bug while accessing the dmabuf- >>name >>>>> under mutex in the dmabuffs_dname(). This is caused from the SELinux >>>>> permissions checks on a process where it tries to validate the inherited >>>>> files from fork() by traversing them through iterate_fd() (which >>>>> traverse files under spin_lock) and call >>>>> match_file(security/selinux/hooks.c) where the permission checks >>> happen. >>>>> This audit information is logged using dump_common_audit_data() >where >>> it >>>>> calls d_path() to get the file path name. If the file check happen on >>>>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex >to >>>>> access dmabuf->name. The flow will be like below: >>>>> flush_unauthorized_files() >>>>> iterate_fd() >>>>>spin_lock() --> Start of the atomic section. >>>>> match_file() >>>>>file_has_perm() >>>>> avc_has_perm() >>>>>avc_audit() >>>>> slow_avc_audit() >>>>> common_lsm_audit() >>>>> dump_common_audit_data() >>>>> audit_log_d_path() >>>>> d_path() >>>>>dmabuffs_dname() >>>>> mutex_lock()--> Sleep while atomic. >>>>> >>>>> Call trace captured (on 4.19 kernels) is below: >>>>> ___might_sleep+0x204/0x208 >>>>> __might_sleep+0x50/0x88 >>>>> __mutex_lock_common+0x5c/0x1068 >>>>> __mutex_lock_common+0x5c/0x1068 >>>>> mutex_lock_nested+0x40/0x50 >>>>> dmabuffs_dname+0xa0/0x170 >>>>> d_path+0x84/0x290 >>>>> audit_log_d_path+0x74/0x130 >>>>> common_lsm_audit+0x334/0x6e8 >>>>> slow_avc_audit+0xb8/0xf8 >>>>> avc_has_perm+0x154/0x218 >>>>> file_has_perm+0x70/0x180 >>>>> match_file+0x60/0x78 >>>>> iterate_fd+0x128/0x168 >>>>> selinux_bprm_committing_creds+0x178/0x248 >>>>> security_bprm_committing_creds+0x30/0x48 >>>>> install_exec_creds+0x1c/0x68 >>>>> load_elf_binary+0x3a4/0x14e0 >>>>> search_binary_handler+0xb0/0x1e0 >>>>> >>>>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. >>>>> >>>>> Cc: [5.3+] >>>>> Signed-off-by: Charan Teja Reddy >>>>> --- >>>>> >>>>> Changes in V2: Addressed review comments from Ruhl, Michael J >>>>> >>>>> Changes in V1: https://lore.kernel.org/patchwork/p
RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan Teja >Kalla >Sent: Monday, June 22, 2020 5:26 AM >To: Ruhl, Michael J ; Sumit Semwal >; david.lai...@aculab.com; open list:DMA >BUFFER SHARING FRAMEWORK ; DRI mailing >list >Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org> >Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name > >Hello Mike, > >On 6/19/2020 7:11 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: charante=codeaurora@mg.codeaurora.org >>> On Behalf Of Charan >Teja >>> Kalla >>> Sent: Friday, June 19, 2020 7:57 AM >>> To: Sumit Semwal ; Ruhl, Michael J >>> ; david.lai...@aculab.com; open list:DMA >>> BUFFER SHARING FRAMEWORK ; DRI >mailing >>> list >>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org> >>> Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name >>> >>> There exists a sleep-while-atomic bug while accessing the dmabuf->name >>> under mutex in the dmabuffs_dname(). This is caused from the SELinux >>> permissions checks on a process where it tries to validate the inherited >>> files from fork() by traversing them through iterate_fd() (which >>> traverse files under spin_lock) and call >>> match_file(security/selinux/hooks.c) where the permission checks >happen. >>> This audit information is logged using dump_common_audit_data() where >it >>> calls d_path() to get the file path name. If the file check happen on >>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to >>> access dmabuf->name. The flow will be like below: >>> flush_unauthorized_files() >>> iterate_fd() >>>spin_lock() --> Start of the atomic section. >>> match_file() >>>file_has_perm() >>> avc_has_perm() >>>avc_audit() >>> slow_avc_audit() >>> common_lsm_audit() >>> dump_common_audit_data() >>> audit_log_d_path() >>> d_path() >>>dmabuffs_dname() >>> mutex_lock()--> Sleep while atomic. >>> >>> Call trace captured (on 4.19 kernels) is below: >>> ___might_sleep+0x204/0x208 >>> __might_sleep+0x50/0x88 >>> __mutex_lock_common+0x5c/0x1068 >>> __mutex_lock_common+0x5c/0x1068 >>> mutex_lock_nested+0x40/0x50 >>> dmabuffs_dname+0xa0/0x170 >>> d_path+0x84/0x290 >>> audit_log_d_path+0x74/0x130 >>> common_lsm_audit+0x334/0x6e8 >>> slow_avc_audit+0xb8/0xf8 >>> avc_has_perm+0x154/0x218 >>> file_has_perm+0x70/0x180 >>> match_file+0x60/0x78 >>> iterate_fd+0x128/0x168 >>> selinux_bprm_committing_creds+0x178/0x248 >>> security_bprm_committing_creds+0x30/0x48 >>> install_exec_creds+0x1c/0x68 >>> load_elf_binary+0x3a4/0x14e0 >>> search_binary_handler+0xb0/0x1e0 >>> >>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. >>> >>> Cc: [5.3+] >>> Signed-off-by: Charan Teja Reddy >>> --- >>> >>> Changes in V2: Addressed review comments from Ruhl, Michael J >>> >>> Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/ >>> >>> drivers/dma-buf/dma-buf.c | 11 +++ >>> include/linux/dma-buf.h | 1 + >>> 2 files changed, 8 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 01ce125..d81d298 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry >*dentry, >>> char *buffer, int buflen) >>> size_t ret = 0; >>> >>> dmabuf = dentry->d_fsdata; >>> - dma_resv_lock(dmabuf->resv, NULL); >>> + spin_lock(>name_lock); >>> if (dmabuf->name) >>> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); >>> - dma_resv_unlock(dmabuf->resv); >>> + spin_unlock(>name_lock); >>> >>> return dynamic_dname(dentry, buffer, buflen, "/%s:%s", >>> dentry->d_name.name, ret > 0 ? name : ""); >>> @@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf >>> *dmabuf, const char __user *buf) >>>
RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>-Original Message-
>From: charante=codeaurora@mg.codeaurora.org
> On Behalf Of Charan Teja
>Kalla
>Sent: Friday, June 19, 2020 7:57 AM
>To: Sumit Semwal ; Ruhl, Michael J
>; david.lai...@aculab.com; open list:DMA
>BUFFER SHARING FRAMEWORK ; DRI mailing
>list
>Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org>
>Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>
>There exists a sleep-while-atomic bug while accessing the dmabuf->name
>under mutex in the dmabuffs_dname(). This is caused from the SELinux
>permissions checks on a process where it tries to validate the inherited
>files from fork() by traversing them through iterate_fd() (which
>traverse files under spin_lock) and call
>match_file(security/selinux/hooks.c) where the permission checks happen.
>This audit information is logged using dump_common_audit_data() where it
>calls d_path() to get the file path name. If the file check happen on
>the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
>access dmabuf->name. The flow will be like below:
>flush_unauthorized_files()
> iterate_fd()
>spin_lock() --> Start of the atomic section.
> match_file()
>file_has_perm()
> avc_has_perm()
>avc_audit()
> slow_avc_audit()
> common_lsm_audit()
> dump_common_audit_data()
> audit_log_d_path()
> d_path()
>dmabuffs_dname()
> mutex_lock()--> Sleep while atomic.
>
>Call trace captured (on 4.19 kernels) is below:
>___might_sleep+0x204/0x208
>__might_sleep+0x50/0x88
>__mutex_lock_common+0x5c/0x1068
>__mutex_lock_common+0x5c/0x1068
>mutex_lock_nested+0x40/0x50
>dmabuffs_dname+0xa0/0x170
>d_path+0x84/0x290
>audit_log_d_path+0x74/0x130
>common_lsm_audit+0x334/0x6e8
>slow_avc_audit+0xb8/0xf8
>avc_has_perm+0x154/0x218
>file_has_perm+0x70/0x180
>match_file+0x60/0x78
>iterate_fd+0x128/0x168
>selinux_bprm_committing_creds+0x178/0x248
>security_bprm_committing_creds+0x30/0x48
>install_exec_creds+0x1c/0x68
>load_elf_binary+0x3a4/0x14e0
>search_binary_handler+0xb0/0x1e0
>
>So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
>
>Cc: [5.3+]
>Signed-off-by: Charan Teja Reddy
>---
>
>Changes in V2: Addressed review comments from Ruhl, Michael J
>
>Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/
>
> drivers/dma-buf/dma-buf.c | 11 +++
> include/linux/dma-buf.h | 1 +
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index 01ce125..d81d298 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry,
>char *buffer, int buflen)
> size_t ret = 0;
>
> dmabuf = dentry->d_fsdata;
>- dma_resv_lock(dmabuf->resv, NULL);
>+ spin_lock(>name_lock);
> if (dmabuf->name)
> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>- dma_resv_unlock(dmabuf->resv);
>+ spin_unlock(>name_lock);
>
> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>dentry->d_name.name, ret > 0 ? name : "");
>@@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf
>*dmabuf, const char __user *buf)
> kfree(name);
> goto out_unlock;
> }
>+ spin_lock(>name_lock);
> kfree(dmabuf->name);
> dmabuf->name = name;
>+ spin_unlock(>name_lock);
While this code path is ok, I would have separated the protection of the
attachment list and the name manipulation.
dma_resv_lock(resv)
if (!list_empty(attachment)
ret = -EBUSY
dma_resv_unlock(resv)
if (ret) {
kfree(name)
return ret;
}
spinlock(nam_lock)
...
Nesting locks that don't need to be nested always makes me nervous
for future use that misses the lock/unlock pattern.
However, this looks reasonable.
With this current code, or if you update to the above pattern:
Reviewed-by: Michael J. Ruhl
Mike
> out_unlock:
> dma_resv_unlock(dmabuf->resv);
>@@ -405,10 +407,10 @@ static void dma_buf_show_fdinfo(struct seq_file
>*m, struct file *file)
> /* Don't count the temporary reference taken inside procfs seq_show
>*/
> seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
> seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
>- dma_resv_lock(dmabuf->resv, NULL);
>+ spin_lock(>name_lock);
> if (dmabuf->name)
RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan Teja >Kalla >Sent: Wednesday, June 17, 2020 2:29 AM >To: Ruhl, Michael J ; Sumit Semwal >; open list:DMA BUFFER SHARING FRAMEWORK >; DRI mailing list de...@lists.freedesktop.org> >Cc: Linaro MM SIG ; >vinme...@codeaurora.org; LKML ; >sta...@vger.kernel.org >Subject: Re: [PATCH] dmabuf: use spinlock to access dmabuf->name > >Thanks Michael for the comments.. > >On 6/16/2020 7:29 PM, Ruhl, Michael J wrote: >>> -----Original Message- >>> From: dri-devel On Behalf Of >>> Ruhl, Michael J >>> Sent: Tuesday, June 16, 2020 9:51 AM >>> To: Charan Teja Kalla ; Sumit Semwal >>> ; open list:DMA BUFFER SHARING >FRAMEWORK >>> ; DRI mailing list >> de...@lists.freedesktop.org> >>> Cc: Linaro MM SIG ; >>> vinme...@codeaurora.org; LKML ; >>> sta...@vger.kernel.org >>> Subject: RE: [PATCH] dmabuf: use spinlock to access dmabuf->name >>> >>>> -Original Message- >>>> From: dri-devel On Behalf Of >>>> Charan Teja Kalla >>>> Sent: Thursday, June 11, 2020 9:40 AM >>>> To: Sumit Semwal ; open list:DMA BUFFER >>>> SHARING FRAMEWORK ; DRI mailing list >>>> de...@lists.freedesktop.org> >>>> Cc: Linaro MM SIG ; >>>> vinme...@codeaurora.org; LKML ; >>>> sta...@vger.kernel.org >>>> Subject: [PATCH] dmabuf: use spinlock to access dmabuf->name >>>> >>>> There exists a sleep-while-atomic bug while accessing the dmabuf->name >>>> under mutex in the dmabuffs_dname(). This is caused from the SELinux >>>> permissions checks on a process where it tries to validate the inherited >>>> files from fork() by traversing them through iterate_fd() (which >>>> traverse files under spin_lock) and call >>>> match_file(security/selinux/hooks.c) where the permission checks >happen. >>>> This audit information is logged using dump_common_audit_data() >where it >>>> calls d_path() to get the file path name. If the file check happen on >>>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex >to >>>> access dmabuf->name. The flow will be like below: >>>> flush_unauthorized_files() >>>> iterate_fd() >>>>spin_lock() --> Start of the atomic section. >>>> match_file() >>>>file_has_perm() >>>> avc_has_perm() >>>>avc_audit() >>>> slow_avc_audit() >>>>common_lsm_audit() >>>> dump_common_audit_data() >>>>audit_log_d_path() >>>> d_path() >>>>dmabuffs_dname() >>>> mutex_lock()--> Sleep while atomic. >>>> >>>> Call trace captured (on 4.19 kernels) is below: >>>> ___might_sleep+0x204/0x208 >>>> __might_sleep+0x50/0x88 >>>> __mutex_lock_common+0x5c/0x1068 >>>> __mutex_lock_common+0x5c/0x1068 >>>> mutex_lock_nested+0x40/0x50 >>>> dmabuffs_dname+0xa0/0x170 >>>> d_path+0x84/0x290 >>>> audit_log_d_path+0x74/0x130 >>>> common_lsm_audit+0x334/0x6e8 >>>> slow_avc_audit+0xb8/0xf8 >>>> avc_has_perm+0x154/0x218 >>>> file_has_perm+0x70/0x180 >>>> match_file+0x60/0x78 >>>> iterate_fd+0x128/0x168 >>>> selinux_bprm_committing_creds+0x178/0x248 >>>> security_bprm_committing_creds+0x30/0x48 >>>> install_exec_creds+0x1c/0x68 >>>> load_elf_binary+0x3a4/0x14e0 >>>> search_binary_handler+0xb0/0x1e0 >>>> >>>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. >>>> >>>> Cc: [5.3+] >>>> Signed-off-by: Charan Teja Reddy >>>> --- >>>> drivers/dma-buf/dma-buf.c | 13 +++-- >>>> include/linux/dma-buf.h | 1 + >>>> 2 files changed, 8 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>>> index 01ce125..2e0456c 100644 >>>> --- a/drivers/dma-buf/dma-buf.c >>>> +++ b/drivers/dma-buf/dma-buf.c >>>> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry >*dentry, >>>> char *buffer, int buflen) >>>>size_t ret = 0; >>>> >>>
RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: dri-devel On Behalf Of >Ruhl, Michael J >Sent: Tuesday, June 16, 2020 9:51 AM >To: Charan Teja Kalla ; Sumit Semwal >; open list:DMA BUFFER SHARING FRAMEWORK >; DRI mailing list de...@lists.freedesktop.org> >Cc: Linaro MM SIG ; >vinme...@codeaurora.org; LKML ; >sta...@vger.kernel.org >Subject: RE: [PATCH] dmabuf: use spinlock to access dmabuf->name > >>-Original Message- >>From: dri-devel On Behalf Of >>Charan Teja Kalla >>Sent: Thursday, June 11, 2020 9:40 AM >>To: Sumit Semwal ; open list:DMA BUFFER >>SHARING FRAMEWORK ; DRI mailing list >de...@lists.freedesktop.org> >>Cc: Linaro MM SIG ; >>vinme...@codeaurora.org; LKML ; >>sta...@vger.kernel.org >>Subject: [PATCH] dmabuf: use spinlock to access dmabuf->name >> >>There exists a sleep-while-atomic bug while accessing the dmabuf->name >>under mutex in the dmabuffs_dname(). This is caused from the SELinux >>permissions checks on a process where it tries to validate the inherited >>files from fork() by traversing them through iterate_fd() (which >>traverse files under spin_lock) and call >>match_file(security/selinux/hooks.c) where the permission checks happen. >>This audit information is logged using dump_common_audit_data() where it >>calls d_path() to get the file path name. If the file check happen on >>the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to >>access dmabuf->name. The flow will be like below: >>flush_unauthorized_files() >> iterate_fd() >>spin_lock() --> Start of the atomic section. >> match_file() >>file_has_perm() >> avc_has_perm() >>avc_audit() >> slow_avc_audit() >> common_lsm_audit() >>dump_common_audit_data() >> audit_log_d_path() >>d_path() >>dmabuffs_dname() >> mutex_lock()--> Sleep while atomic. >> >>Call trace captured (on 4.19 kernels) is below: >>___might_sleep+0x204/0x208 >>__might_sleep+0x50/0x88 >>__mutex_lock_common+0x5c/0x1068 >>__mutex_lock_common+0x5c/0x1068 >>mutex_lock_nested+0x40/0x50 >>dmabuffs_dname+0xa0/0x170 >>d_path+0x84/0x290 >>audit_log_d_path+0x74/0x130 >>common_lsm_audit+0x334/0x6e8 >>slow_avc_audit+0xb8/0xf8 >>avc_has_perm+0x154/0x218 >>file_has_perm+0x70/0x180 >>match_file+0x60/0x78 >>iterate_fd+0x128/0x168 >>selinux_bprm_committing_creds+0x178/0x248 >>security_bprm_committing_creds+0x30/0x48 >>install_exec_creds+0x1c/0x68 >>load_elf_binary+0x3a4/0x14e0 >>search_binary_handler+0xb0/0x1e0 >> >>So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. >> >>Cc: [5.3+] >>Signed-off-by: Charan Teja Reddy >>--- >> drivers/dma-buf/dma-buf.c | 13 +++-- >> include/linux/dma-buf.h | 1 + >> 2 files changed, 8 insertions(+), 6 deletions(-) >> >>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>index 01ce125..2e0456c 100644 >>--- a/drivers/dma-buf/dma-buf.c >>+++ b/drivers/dma-buf/dma-buf.c >>@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry, >>char *buffer, int buflen) >> size_t ret = 0; >> >> dmabuf = dentry->d_fsdata; >>- dma_resv_lock(dmabuf->resv, NULL); >>+ spin_lock(>name_lock); >> if (dmabuf->name) >> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); >>- dma_resv_unlock(dmabuf->resv); >>+ spin_unlock(>name_lock); > >I am not really clear on why you need this lock. > >If name == NULL you have no issues. >If name is real, you have no issues. > >If name is freed you will copy garbage, but the only way >for that to happen is that _set_name or _release have to be called >at just the right time. > >And the above would probably only be an issue if the set_name >was called, so you will get NULL or a real name. > >Is there a reason for the lock here? > >Mike Maybe dmabuf->name = NULL after the kfree(dmabuf->name) in: dma_buf_release() Would be sufficient? M >> return dynamic_dname(dentry, buffer, buflen, "/%s:%s", >> dentry->d_name.name, ret > 0 ? name : ""); >>@@ -335,7 +335,7 @@ static long dma_buf_set_name(struct dma_buf >>*dmabuf, const char __user *buf) >> if (IS_ERR(name)) >> return PTR_ERR(name); >> >>- dma_resv_lock(d
RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>-Original Message-
>From: dri-devel On Behalf Of
>Charan Teja Kalla
>Sent: Thursday, June 11, 2020 9:40 AM
>To: Sumit Semwal ; open list:DMA BUFFER
>SHARING FRAMEWORK ; DRI mailing list de...@lists.freedesktop.org>
>Cc: Linaro MM SIG ;
>vinme...@codeaurora.org; LKML ;
>sta...@vger.kernel.org
>Subject: [PATCH] dmabuf: use spinlock to access dmabuf->name
>
>There exists a sleep-while-atomic bug while accessing the dmabuf->name
>under mutex in the dmabuffs_dname(). This is caused from the SELinux
>permissions checks on a process where it tries to validate the inherited
>files from fork() by traversing them through iterate_fd() (which
>traverse files under spin_lock) and call
>match_file(security/selinux/hooks.c) where the permission checks happen.
>This audit information is logged using dump_common_audit_data() where it
>calls d_path() to get the file path name. If the file check happen on
>the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
>access dmabuf->name. The flow will be like below:
>flush_unauthorized_files()
> iterate_fd()
>spin_lock() --> Start of the atomic section.
> match_file()
>file_has_perm()
> avc_has_perm()
>avc_audit()
> slow_avc_audit()
> common_lsm_audit()
> dump_common_audit_data()
> audit_log_d_path()
> d_path()
>dmabuffs_dname()
> mutex_lock()--> Sleep while atomic.
>
>Call trace captured (on 4.19 kernels) is below:
>___might_sleep+0x204/0x208
>__might_sleep+0x50/0x88
>__mutex_lock_common+0x5c/0x1068
>__mutex_lock_common+0x5c/0x1068
>mutex_lock_nested+0x40/0x50
>dmabuffs_dname+0xa0/0x170
>d_path+0x84/0x290
>audit_log_d_path+0x74/0x130
>common_lsm_audit+0x334/0x6e8
>slow_avc_audit+0xb8/0xf8
>avc_has_perm+0x154/0x218
>file_has_perm+0x70/0x180
>match_file+0x60/0x78
>iterate_fd+0x128/0x168
>selinux_bprm_committing_creds+0x178/0x248
>security_bprm_committing_creds+0x30/0x48
>install_exec_creds+0x1c/0x68
>load_elf_binary+0x3a4/0x14e0
>search_binary_handler+0xb0/0x1e0
>
>So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
>
>Cc: [5.3+]
>Signed-off-by: Charan Teja Reddy
>---
> drivers/dma-buf/dma-buf.c | 13 +++--
> include/linux/dma-buf.h | 1 +
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index 01ce125..2e0456c 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry,
>char *buffer, int buflen)
> size_t ret = 0;
>
> dmabuf = dentry->d_fsdata;
>- dma_resv_lock(dmabuf->resv, NULL);
>+ spin_lock(>name_lock);
> if (dmabuf->name)
> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>- dma_resv_unlock(dmabuf->resv);
>+ spin_unlock(>name_lock);
I am not really clear on why you need this lock.
If name == NULL you have no issues.
If name is real, you have no issues.
If name is freed you will copy garbage, but the only way
for that to happen is that _set_name or _release have to be called
at just the right time.
And the above would probably only be an issue if the set_name
was called, so you will get NULL or a real name.
Is there a reason for the lock here?
Mike
> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>dentry->d_name.name, ret > 0 ? name : "");
>@@ -335,7 +335,7 @@ static long dma_buf_set_name(struct dma_buf
>*dmabuf, const char __user *buf)
> if (IS_ERR(name))
> return PTR_ERR(name);
>
>- dma_resv_lock(dmabuf->resv, NULL);
>+ spin_lock(>name_lock);
> if (!list_empty(>attachments)) {
> ret = -EBUSY;
> kfree(name);
>@@ -345,7 +345,7 @@ static long dma_buf_set_name(struct dma_buf
>*dmabuf, const char __user *buf)
> dmabuf->name = name;
>
> out_unlock:
>- dma_resv_unlock(dmabuf->resv);
>+ spin_unlock(>name_lock);
> return ret;
> }
>
>@@ -405,10 +405,10 @@ static void dma_buf_show_fdinfo(struct seq_file
>*m, struct file *file)
> /* Don't count the temporary reference taken inside procfs seq_show
>*/
> seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
> seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
>- dma_resv_lock(dmabuf->resv, NULL);
>+ spin_lock(>name_lock);
> if (dmabuf->name)
> seq_printf(m, "name:\t%s\n", dmabuf->name);
>- dma_resv_unlock(dmabuf->resv);
>+ spin_unlock(>name_lock);
> }
>
> static const struct file_operations dma_buf_fops = {
>@@ -546,6 +546,7 @@ struct dma_buf *dma_buf_export(const struct
>dma_buf_export_info *exp_info)
> dmabuf->size = exp_info->size;
> dmabuf->exp_name = exp_info->exp_name;
> dmabuf->owner = exp_info->owner;
>+ spin_lock_init(>name_lock);
> init_waitqueue_head(>poll);
>
RE: [PATCH 07/15] drm/amdgpu: use PCI_IRQ_MSI_TYPES where appropriate
>-Original Message-
>From: dri-devel On Behalf Of
>Piotr Stankiewicz
>Sent: Tuesday, June 2, 2020 5:21 AM
>To: Alex Deucher ; Christian König
>; David Zhou ; David
>Airlie ; Daniel Vetter
>Cc: Stankiewicz, Piotr ; dri-
>de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org
>Subject: [PATCH 07/15] drm/amdgpu: use PCI_IRQ_MSI_TYPES where
>appropriate
>
>Seeing as there is shorthand available to use when asking for any type
>of interrupt, or any type of message signalled interrupt, leverage it.
>
>Signed-off-by: Piotr Stankiewicz
>Reviewed-by: Andy Shevchenko
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>index 5ed4227f304b..6dbe173a9fd4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>@@ -251,11 +251,11 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
> int nvec = pci_msix_vec_count(adev->pdev);
> unsigned int flags;
>
>- if (nvec <= 0) {
>+ if (nvec > 0)
>+ flags = PCI_IRQ_MSI_TYPES;
>+ else
> flags = PCI_IRQ_MSI;
>- } else {
>- flags = PCI_IRQ_MSI | PCI_IRQ_MSIX;
>- }
Minor nit:
Is it really necessary to set do this check? Can flags just
be set?
I.e.:
flags = PCI_IRQ_MSI_TYPES;
pci_alloc_irq_vector() tries stuff in order. If MSIX is not available,
it will try MSI.
M
>+
> /* we only need one vector */
> nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1, flags);
> if (nvec > 0) {
>--
>2.17.2
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling
>-Original Message-
>From: Dan Carpenter
>Sent: Wednesday, May 20, 2020 11:26 AM
>To: Alex Deucher ; Kevin Wang
>; Ruhl, Michael J
>Cc: Christian König ; David Airlie
>; Daniel Vetter ; Evan Quan
>; Rui Huang ; Kenneth Feng
>; Yintian Tao ; Hawking Zhang
>; amd-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel-
>janit...@vger.kernel.org
>Subject: [PATCH v3] drm/amdgpu: off by one in
>amdgpu_device_attr_create_groups() error handling
>
>This loop in the error handling code should start a "i - 1" and end at
>"i == 0". Currently it starts a "i" and ends at "i == 1". The result
>is that it removes one attribute that wasn't created yet, and leaks the
>zeroeth attribute.
>
>Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
>Signed-off-by: Dan Carpenter
>---
>v2: style change
>v3: Fix embarrassing typo in the subject
Acked-by: Michael J. Ruhl
m
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>index b75362bf0742..e809534fabd4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
>amdgpu_device *adev,
> return 0;
>
> failed:
>- for (; i > 0; i--) {
>+ while (i--)
> amdgpu_device_attr_remove(adev, [i]);
>- }
>
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling
"off by on"
or
"off by one"
?
M
>-Original Message-
>From: dri-devel On Behalf Of Dan
>Carpenter
>Sent: Wednesday, May 20, 2020 9:08 AM
>To: Alex Deucher ; Kevin Wang
>
>Cc: David Airlie ; kernel-janit...@vger.kernel.org; linux-
>ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Hawking Zhang
>; Rui Huang ; dri-
>de...@lists.freedesktop.org; Evan Quan ; Kenneth
>Feng ; Christian König
>; Yintian Tao
>Subject: [PATCH v2] drm/amdgpu: off by on in
>amdgpu_device_attr_create_groups() error handling
>
>This loop in the error handling code should start a "i - 1" and end at
>"i == 0". Currently it starts a "i" and ends at "i == 1". The result
>is that it removes one attribute that wasn't created yet, and leaks the
>zeroeth attribute.
>
>Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
>Signed-off-by: Dan Carpenter
>---
>v2: style change
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>index b75362bf0742..e809534fabd4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
>amdgpu_device *adev,
> return 0;
>
> failed:
>- for (; i > 0; i--) {
>+ while (i--)
> amdgpu_device_attr_remove(adev, [i]);
>- }
>
> return ret;
> }
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
