dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] [RESEND] drm/rcar: stop using 'imply' for dependencies
by Arnd Bergmann 09 Nov '21

09 Nov '21

From: Arnd Bergmann <arnd(a)arndb.de> The meaning of the 'imply' keyword has changed recently, and neither the old meaning (select the symbol if its dependencies are met) nor the new meaning (enable it by default, but let the user set any other setting) is what we want here. Work around this by adding two more Kconfig options that lead to the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS are enabled, that portion of the driver becomes usable, and no configuration results in a link error. This avoids a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin': rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable' arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': Link: https://lore.kernel.org/all/20200417155553.675905-5-arnd@arndb.de/ Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- This was last posted as part of a longer series to rework the DRM dependencies in a more logical way. The rest of the series is still open, but this one is needed as a bug fix regardless of the rest. --- drivers/gpu/drm/rcar-du/Kconfig | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index b47e74421e34..3e588ddba245 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -4,8 +4,6 @@ config DRM_RCAR_DU depends on DRM && OF depends on ARM || ARM64 depends on ARCH_RENESAS || COMPILE_TEST - imply DRM_RCAR_CMM - imply DRM_RCAR_LVDS select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER @@ -14,13 +12,17 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. -config DRM_RCAR_CMM - tristate "R-Car DU Color Management Module (CMM) Support" - depends on DRM && OF +config DRM_RCAR_USE_CMM + bool "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU + default DRM_RCAR_DU help Enable support for R-Car Color Management Module (CMM). +config DRM_RCAR_CMM + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_CMM + config DRM_RCAR_DW_HDMI tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support" depends on DRM && OF @@ -28,15 +30,20 @@ config DRM_RCAR_DW_HDMI help Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder. +config DRM_RCAR_USE_LVDS + bool "R-Car DU LVDS Encoder Support" + depends on DRM_BRIDGE && OF + default DRM_RCAR_DU + help + Enable support for the R-Car Display Unit embedded LVDS encoders. + config DRM_RCAR_LVDS - tristate "R-Car DU LVDS Encoder Support" - depends on DRM && DRM_BRIDGE && OF + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_LVDS select DRM_KMS_HELPER select DRM_PANEL select OF_FLATTREE select OF_OVERLAY - help - Enable support for the R-Car Display Unit embedded LVDS encoders. config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM -- 2.29.2

3 2

[PATCH] doc: gpu: Add document describing buffer exchange
by Daniel Stone 09 Nov '21

09 Nov '21

Since there's a lot of confusion around this, document both the rules and the best practice around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dmabuf, formats and modifiers, and their usage. Signed-off-by: Daniel Stone <daniels(a)collabora.com> --- This is just a quick first draft, inspired by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3197#note_1048637 It's not complete or perfect, but I'm off to eat a roast then have a nice walk in the sun, so figured it'd be better to dash it off rather than let it rot on my hard drive. .../gpu/exchanging-pixel-buffers.rst | 285 ++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 286 insertions(+) create mode 100644 Documentation/gpu/exchanging-pixel-buffers.rst diff --git a/Documentation/gpu/exchanging-pixel-buffers.rst b/Documentation/gpu/exchanging-pixel-buffers.rst new file mode 100644 index 000000000000..75c4de13d5c8 --- /dev/null +++ b/Documentation/gpu/exchanging-pixel-buffers.rst @@ -0,0 +1,285 @@ +.. Copyright 2021 Collabora Ltd. + +======================== +Exchanging pixel buffers +======================== + +As originally designed, the Linux graphics subsystem had extremely limited +support for sharing pixel-buffer allocations between processes, devices, and +subsystems. Modern systems require extensive integration between all three +classes; this document details how applications and kernel subsystems should +approach this sharing for two-dimensional image data. + +It is written with reference to the DRM subsystem for GPU and display devices, +V4L2 for media devices, and also to Vulkan, EGL and Wayland, for userspace +support, however any other subsystems should also follow this design and advice. + + +Formats and modifiers +===================== + +Each buffer must have an underlying format. This format describes the data which +can be stored and loaded for each pixel. Although each subsystem has its own +format descriptions (e.g. V4L2 and fbdev), the `DRM_FORMAT_*` tokens should be +reused wherever possible, as they are the standard descriptions used for +interchange. + +Each `DRM_FORMAT_*` token describes the per-pixel data available, in terms of +the translation between one or more pixels in memory, and the color data +contained within that memory. The number and type of color channels are +described: whether they are RGB or YUV, integer or floating-point, the size +of each channel and their locations within the pixel memory, and the +relationship between color planes. + +For example, `DRM_FORMAT_ARGB8888` describes a format in which each pixel has a +single 32-bit value in memory. Alpha, red, green, and blue, color channels are +available at 8-byte precision per channel, ordered respectively from most to +least significant bits in little-endian storage. As a more complex example, +`DRM_FORMAT_NV12` describes a format in which luma and chroma YUV samples are +stored in separate memory planes, where the chroma plane is stored at half the +resolution in both dimensions (i.e. one U/V chroma sample is stored for each 2x2 +pixel grouping). + +Format modifiers describe a translation mechanism between these per-pixel memory +samples, and the actual memory storage for the buffer. The most straightforward +modifier is `DRM_FORMAT_MOD_LINEAR`, describing a scheme in which each pixel has +contiguous storage beginning at (0,0); each pixel's location in memory will be +`base + (y * stride) + (x * bpp)`. This is considered the baseline interchange +format, and most convenient for CPU access. + +Modern hardware employs much more sophisticated access mechanisms, typically +making use of tiled access and possibly also compression. For example, the +`DRM_FORMAT_MOD_VIVANTE_TILED` modifier describes memory storage where pixels +are stored in 4x4 blocks arranged in row-major ordering, i.e. the first tile in +memory stores pixels (0,0) to (3,3) inclusive, and the second tile in memory +stores pixels (4,0) to (7,3) inclusive. + +Some modifiers may modify the number of memory buffers required to store the +data; for example, the `I915_FORMAT_MOD_Y_TILED_CCS` modifier adds a second +memory buffer to RGB formats in which it stores data about the status of every +tile, notably including whether the tile is fully populated with pixel data, or +can be expanded from a single solid color. + +These extended layouts are highly vendor-specific, and even specific to +particular generations or configurations of devices per-vendor. For this reason, +support of modifiers must be explicitly enumerated and negotiated by all users +in order to ensure a compatible and optimal pipeline, as discussed below. + + +Dimensions and size +=================== + +Each pixel buffer must be accompanied by logical pixel dimensions. This refers +to the number of unique samples which can be extracted from, or stored to, the +underlying memory storage. For example, even though a 1920x1080 +`DRM_FORMAT_NV12` buffer has a luma plane containing 1920x1080 samples for the Y +component, and 960x540 samples for the U and V components, the overall buffer is +still described as having dimensions of 1920x1080. + +The in-memory storage of a buffer is not guaranteed to begin immediately at the +base address of the underlying memory, nor is it guaranteed that the memory +storage is tightly clipped to either dimension. + +Each plane must therefore be described with an `offset` in bytes, which will be +added to the base address of the memory storage before performing any per-pixel +calculations. This may be used to combine multiple planes into a single pixel +buffer; for example, `DRM_FORMAT_NV12` may be stored in a single memory buffer +where the luma plane's storage begins immediately at the start of the buffer +with an offset of 0, and the chroma plane's storage begins after the offset of +the luma plane as expressed through its offset. + +Each plane must also have a `stride` in bytes, expressing the offset in memory +between two contiguous scanlines. For example, a `DRM_FORMAT_MOD_LINEAR` buffer +with dimensions of 1000x1000 may have been allocated as if it were 1024x1000, in +order to allow for aligned access patterns. In this case, the buffer will still +be described with a width of 1000, however the stride will be `1024 * bpp`, +indicating that there are 24 pixels at the positive extreme of the x axis whose +values are not significant. + +Buffers may also be padded further in the y dimension, simply by allocating a +larger area than would ordinarily be required. For example, many media decoders +are not able to natively output buffers of height 1080, but instead require an +effective height of 1088 pixels. In this case, the buffer continues to be +described as having a height of 1080, with the memory allocation for each buffer +being increased to account for the extra padding. + + +Enumeration +=========== + +Every user of pixel buffers must be able to enumerate a set of supported formats +and modifiers, described together. Within KMS, this is achieved with the +`IN_FORMATS` property on each DRM plane, listing the supported DRM formats, and +the modifiers supported for each format. In userspace, this is supported through +the `EGL_EXT_image_dma_buf_import_modifiers` extension entrypoints for EGL, the +`VK_EXT_image_drm_format_modifier` extension for Vulkan, and the +`zwp_linux_dmabuf_v1` extension for Wayland. + +Each of these interfaces allows users to query a set of supported +format+modifier combinations. + + +Negotiation +=========== + +It is the responsibility of userspace to negotiate an acceptable format+modifier +combination for its usage. This is performed through a simple intersection of +lists. For example, if a user wants to use Vulkan to render an image to be +displayed on a KMS plane, it must: + - query KMS for the `IN_FORMATS` property for the given plane + - query Vulkan for the supported formats for its physical device + - intersect these formats to determine the most appropriate one + - for this format, intersect the lists of supported modifiers for both KMS and + Vulkan, to obtain a final list of acceptable modifiers for that format + +This intersection must be performed for all usages. For example, if the user +also wishes to encode the image to a video stream, it must query the media API +it intends to use for encoding for the set of modifiers it supports, and +additionally intersect against this list. + +If the intersection of all lists is an empty list, it is not possible to share +buffers in this way, and an alternate strategy must be considered (e.g. using +CPU access routines to copy data between the different uses, with the +corresponding performance cost). + +The resulting modifier list is unsorted; the order is not significant. + + +Allocation +========== + +Once userspace has determined an appropriate format, and corresponding list of +acceptable modifiers, it must allocate the buffer. As there is no universal +buffer-allocation interface available at either kernel or userspace level, the +client makes an arbitrary choice of allocation interface such as Vulkan, GBM, or +a media API. + +Each allocation request must take, at a minimum: the pixel format, a list of +acceptable modifiers, and the buffer's width and height. Each API may extend +this set of properties in different ways, such as allowing allocation in more +than two dimensions, intended usage patterns, etc. + +The component which allocates the buffer will make an arbitrary choice of what +it considers the 'best' modifier within the acceptable list for the requested +allocation, any padding required, and further properties of the underlying +memory buffers such as whether they are stored in system or device-specific +memory, whether or not they are physically contiguous, and their cache mode. +These properties of the memory buffer are not visible to userspace, however the +`dma-heaps` API is an effort to address this. + +After allocation, the client must query the allocator to determine the actual +modifier selected for the buffer, as well as the per-plane offset and stride. +Allocators are not permitted to vary the format in use, to select a modifier not +provided within the acceptable list, nor to vary the pixel dimensions other than +the padding expressed through offset, stride, and size. + + +Import +====== + +To use a buffer within a different context, device, or subsystem, the user +passes these parameters (format, modifier, width, height, and per-plane offset +and stride) to an importing API. + +Each memory plane is referred to by a buffer handle, which may be unique or +duplicated within a buffer. For example, a `DRM_FORMAT_NV12` buffer may have the +luma and chroma buffers combined into a single memory buffer by use of the +per-plane offset parameters, or they may be completely separate allocations in +memory. For this reason, each import and allocation API must provide a separate +handle for each plane. + +Each kernel subsystem has its own types and interfaces for buffer management. +DRM uses GEM buffer objects (BOs), V4L2 has its own references, etc. These types +are not portable between contexts, processes, devices, or subsystems. + +To address this, `dma-buf` handles are used as the universal interchange for +buffers. Subsystem-specific operations are used to export native buffer handles +to a `dma-buf` file descriptor, and to import those file descriptors into a +native buffer handle. dma-buf file descriptors can be transferred between +contexts, processes, devices, and subsystems. + +For example, a Wayland media player may use V4L2 to decode a video frame into +a `DRM_FORMAT_NV12` buffer. This will result in two memory planes (luma and +chroma) being dequeued by the user from V4L2. These planes are then exported to +one dma-buf file descriptor per plane, these descriptors are then sent along +with the metadata (format, modifier, width, height, per-plane offset and stride) +to the Wayland server. The Wayland server will then import these file +descriptors as an EGLImage for use through EGL/OpenGL (ES), a VkImage for use +through Vulkan, or a `drm_fb` for use through KMS; each of these import +operations will take the same metadata and convert the dma-buf file descriptors +into their native buffer handles. + + +Implicit modifiers +================== + +The concept of modifiers post-dates all of the subsystems mentioned above. As +such, it has been retrofitted into all of these APIs, and in order to ensure +backwards compatibility, support is needed for drivers and userspace which do +not (yet) support modifiers. + +As an example, GBM is used to allocate buffers to be shared between EGL for +rendering and KMS for display. It has two entrypoints for allocating buffers: +`gbm_bo_create` which only takes the format, width, height, and a usage token, +and `gbm_bo_create_with_modifiers` which extends this with a list of modifiers. + +In the latter case, the allocation is as discussed above, being provided with a +list of acceptable modifiers that the implementation can choose from (or fail if +it is not possible to allocate within those constraints). In the former case +where modifiers are not provided, the GBM implementation must make its own +choice as to what is likely to be the 'best' layout. Such a choice is entirely +implementation-specific: some will internally use tiled layouts which are not +CPU-accessible if the implementation decides that is a good idea through +whatever heuristic. It is the implementation's responsibility to ensure that +this choice is appropriate. + +To support this case where the layout is not known because there is no awareness +of modifiers, a special `DRM_FORMAT_MOD_INVALID` token has been defined. This +pseudo-modifier declares that the layout is not known, and that the driver +should use its own logic to determine what the underlying layout may be. + +There are four cases where this token may be used: + - during enumeration, an interface may return `DRM_FORMAT_MOD_INVALID`, either + as the sole member of a modifier list to declare that explicit modifiers are + not supported, or as part of a larger list to declare that implicit modifiers + may be used + - during allocation, a user may supply `DRM_FORMAT_MOD_INVALID`, either as the + sole member of a modifier list (equivalent to not supplying a modifier list + at all) to declare that explicit modifiers are not supported and must not be + used, or as part of a larger list to declare that an allocation using implicit + modifiers is acceptable + - in a post-allocation query, an implementation may return + `DRM_FORMAT_MOD_INVALID` as the modifier of the allocated buffer to declare + that the underlying layout is implementation-defined and that an explicit + modifier description is not available; per the above rules, this may only be + returned when the user has included `DRM_FORMAT_MOD_INVALID` as part of the + list of acceptable modifiers, or not provided a list + - when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the + buffer modifier (or not supply a modifier) to indicate that the modifier is + unknown for whatever reason; this is only acceptable when the buffer has + not been allocated with an explicit modifier + +It follows from this that a buffer chain must be either fully implicit or fully +explicit. For example, if a user wishes to allocate a buffer for use between +GPU, display, and media, but the media API does not support modifiers, then the +user **must not** allocate the buffer with explicit modifiers and attempt to +import the buffer into the media API with no modifier, but either perform the +allocation using implicit modifiers, or allocate the buffer for media use +separately and copy between the two buffers. + +As one exception to the above, allocations may be 'upgraded' from implicit +to explicit modifiers. For example, if the buffer is allocated with +`gbm_bo_create` (taking no modifiers), the user may then query the modifier with +`gbm_bo_get_modifier` and then use this modifier as an explicit modifier token +if a valid modifier is returned. + +When allocating buffers for exchange between different users and modifiers are +not available, implementations are strongly encouraged to use +`DRM_FORMAT_MOD_LINEAR` for their allocation, as this is the universal baseline +for exchange. + +Any new users - userspace programs and protocols, kernel subsystems, etc - +wishing to exchange buffers must offer interoperability through dma-buf file +descriptors for memory planes, DRM format tokens to describe the format, DRM +format modifiers to describe the layout in memory, at least width and height for +dimensions, and at least offset and stride for each memory plane. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..cb12f2654ed7 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + exchanging-pixel-buffers driver-uapi drm-client drivers -- 2.31.1

6 10

[PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
by Daniel Vetter 08 Nov '21

08 Nov '21

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. Since this has been shipping for years already compositors need to deal no matter what, so as a first step just try to enforce this across drivers better with some checks. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). v4: Drop the uapi changes, only add a WARN_ON for now to enforce some rules for drivers. v5: Make the WARNING more informative (Daniel) v6: Add unconditional debug output for compositor hackers to figure out what's going on when they get an EBUSY (Daniel) v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville) References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: Simon Ser <contact(a)emersion.fr> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 58527f151984..aac9122f1da2 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free); * needed. It will also grab the relevant CRTC lock to make sure that the state * is consistent. * + * WARNING: Drivers may only add new CRTC states to a @state if + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit + * not created by userspace through an IOCTL call. + * * Returns: * * Either the allocated state or the error code encoded into the pointer. When @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state) struct drm_crtc_state *new_crtc_state; struct drm_connector *conn; struct drm_connector_state *conn_state; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; int i, ret = 0; DRM_DEBUG_ATOMIC("checking %p\n", state); + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); + for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) { ret = drm_atomic_plane_check(old_plane_state, new_plane_state); if (ret) { @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * This can cause spurious EBUSY, which robs compositors of a very + * effective sanity check for their drawing loop. Therefor only allow + * drivers to add unrelated CRTC states for modeset commits. + * + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output + * so compositors know what's going on. + */ + if (affected_crtc != requested_crtc) { + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + } + return 0; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.28.0

5 8

Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board
by Christian Zigotzky 08 Nov '21

08 Nov '21

Hello, The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4]. This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5]. I bisected today [6]. Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit. I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes. After that I created a patch for reverting this commit for new git test kernels. [3] The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files. Please check the first bad commit. Thanks, Christian [1] https://en.wikipedia.org/wiki/AmigaOne_X1000 [2] http://wiki.amiga.org/index.php?title=X5000 [3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4377 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074 [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3

5 10

[PATCH] kernel/locking: Add context to ww_mutex_trylock.
by Maarten Lankhorst 04 Nov '21

04 Nov '21

i915 will soon gain an eviction path that trylock a whole lot of locks for eviction, getting dmesg failures like below: BUG: MAX_LOCK_DEPTH too low! turning off the locking correctness validator. depth: 48 max: 48! 48 locks held by i915_selftest/5776: #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160 #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915] #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915] #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915] #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] ... #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] INFO: lockdep is turned off. Fixing eviction to nest into ww_class_acquire is a high priority, but it requires a rework of the entire driver, which can only be done one step at a time. As an intermediate solution, add an acquire context to ww_mutex_trylock, which allows us to do proper nesting annotations on the trylocks, making the above lockdep splat disappear. This is also useful in regulator_lock_nested, which may avoid dropping regulator_nesting_mutex in the uncontended path, so use it there. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Will Deacon <will(a)kernel.org> Cc: Waiman Long <longman(a)redhat.com> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/drm_modeset_lock.c | 2 +- drivers/regulator/core.c | 2 +- include/linux/dma-resv.h | 2 +- include/linux/ww_mutex.h | 13 +---- kernel/locking/mutex.c | 38 +++++++++++++ kernel/locking/test-ww_mutex.c | 86 ++++++++++++++++++++++-------- lib/locking-selftest.c | 2 +- 7 files changed, 109 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index fcfe1a03c4a1..bf8a6e823a15 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -248,7 +248,7 @@ static inline int modeset_lock(struct drm_modeset_lock *lock, if (ctx->trylock_only) { lockdep_assert_held(&ctx->ww_ctx); - if (!ww_mutex_trylock(&lock->mutex)) + if (!ww_mutex_trylock(&lock->mutex, NULL)) return -EBUSY; else return 0; diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ca6caba8a191..f4d441b1a8bf 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -145,7 +145,7 @@ static inline int regulator_lock_nested(struct regulator_dev *rdev, mutex_lock(&regulator_nesting_mutex); - if (ww_ctx || !ww_mutex_trylock(&rdev->mutex)) { + if (!ww_mutex_trylock(&rdev->mutex, ww_ctx)) { if (rdev->mutex_owner == current) rdev->ref_cnt++; else diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index e1ca2080a1ff..39fefb86780b 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -173,7 +173,7 @@ static inline int dma_resv_lock_slow_interruptible(struct dma_resv *obj, */ static inline bool __must_check dma_resv_trylock(struct dma_resv *obj) { - return ww_mutex_trylock(&obj->lock); + return ww_mutex_trylock(&obj->lock, NULL); } /** diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index b77f39f319ad..0b8f28577c00 100644 --- a/include/linux/ww_mutex.h +++ b/include/linux/ww_mutex.h @@ -313,17 +313,8 @@ ww_mutex_lock_slow_interruptible(struct ww_mutex *lock, extern void ww_mutex_unlock(struct ww_mutex *lock); -/** - * ww_mutex_trylock - tries to acquire the w/w mutex without acquire context - * @lock: mutex to lock - * - * Trylocks a mutex without acquire context, so no deadlock detection is - * possible. Returns 1 if the mutex has been acquired successfully, 0 otherwise. - */ -static inline int __must_check ww_mutex_trylock(struct ww_mutex *lock) -{ - return mutex_trylock(&lock->base); -} +int __must_check ww_mutex_trylock(struct ww_mutex *lock, + struct ww_acquire_ctx *ctx); /*** * ww_mutex_destroy - mark a w/w mutex unusable diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index d2df5e68b503..5d0f5b04b568 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -1112,6 +1112,44 @@ __ww_mutex_lock(struct mutex *lock, unsigned int state, unsigned int subclass, return __mutex_lock_common(lock, state, subclass, nest_lock, ip, ww_ctx, true); } +/** + * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire context + * @lock: mutex to lock + * @ctx: optional w/w acquire context + * + * Trylocks a mutex with the optional acquire context; no deadlock detection is + * possible. Returns 1 if the mutex has been acquired successfully, 0 otherwise. + * + * Unlike ww_mutex_lock, no deadlock handling is performed. However, if a @ctx is + * specified, -EALREADY and -EDEADLK handling may happen in calls to ww_mutex_lock. + * + * A mutex acquired with this function must be released with ww_mutex_unlock. + */ +int __sched +ww_mutex_trylock(struct ww_mutex *ww, struct ww_acquire_ctx *ctx) +{ + bool locked; + + if (!ctx) + return mutex_trylock(&ww->base); + +#ifdef CONFIG_DEBUG_MUTEXES + DEBUG_LOCKS_WARN_ON(ww->base.magic != &ww->base); +#endif + + preempt_disable(); + locked = __mutex_trylock(&ww->base); + + if (locked) { + ww_mutex_set_context_fastpath(ww, ctx); + mutex_acquire_nest(&ww->base.dep_map, 0, 1, &ctx->dep_map, _RET_IP_); + } + preempt_enable(); + + return locked; +} +EXPORT_SYMBOL(ww_mutex_trylock); + #ifdef CONFIG_DEBUG_LOCK_ALLOC void __sched mutex_lock_nested(struct mutex *lock, unsigned int subclass) diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c index 3e82f449b4ff..d63ac411f367 100644 --- a/kernel/locking/test-ww_mutex.c +++ b/kernel/locking/test-ww_mutex.c @@ -16,6 +16,15 @@ static DEFINE_WD_CLASS(ww_class); struct workqueue_struct *wq; +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH +#define ww_acquire_init_noinject(a, b) do { \ + ww_acquire_init((a), (b)); \ + (a)->deadlock_inject_countdown = ~0U; \ + } while (0) +#else +#define ww_acquire_init_noinject(a, b) ww_acquire_init((a), (b)) +#endif + struct test_mutex { struct work_struct work; struct ww_mutex mutex; @@ -36,7 +45,7 @@ static void test_mutex_work(struct work_struct *work) wait_for_completion(&mtx->go); if (mtx->flags & TEST_MTX_TRY) { - while (!ww_mutex_trylock(&mtx->mutex)) + while (!ww_mutex_trylock(&mtx->mutex, NULL)) cond_resched(); } else { ww_mutex_lock(&mtx->mutex, NULL); @@ -109,19 +118,38 @@ static int test_mutex(void) return 0; } -static int test_aa(void) +static int test_aa(bool trylock) { struct ww_mutex mutex; struct ww_acquire_ctx ctx; int ret; + const char *from = trylock ? "trylock" : "lock"; ww_mutex_init(&mutex, &ww_class); ww_acquire_init(&ctx, &ww_class); - ww_mutex_lock(&mutex, &ctx); + if (!trylock) { + ret = ww_mutex_lock(&mutex, &ctx); + if (ret) { + pr_err("%s: initial lock failed!\n", __func__); + goto out; + } + } else { + if (!ww_mutex_trylock(&mutex, &ctx)) { + pr_err("%s: initial trylock failed!\n", __func__); + goto out; + } + } - if (ww_mutex_trylock(&mutex)) { - pr_err("%s: trylocked itself!\n", __func__); + if (ww_mutex_trylock(&mutex, NULL)) { + pr_err("%s: trylocked itself without context from %s!\n", __func__, from); + ww_mutex_unlock(&mutex); + ret = -EINVAL; + goto out; + } + + if (ww_mutex_trylock(&mutex, &ctx)) { + pr_err("%s: trylocked itself with context from %s!\n", __func__, from); ww_mutex_unlock(&mutex); ret = -EINVAL; goto out; @@ -129,17 +157,17 @@ static int test_aa(void) ret = ww_mutex_lock(&mutex, &ctx); if (ret != -EALREADY) { - pr_err("%s: missed deadlock for recursing, ret=%d\n", - __func__, ret); + pr_err("%s: missed deadlock for recursing, ret=%d from %s\n", + __func__, ret, from); if (!ret) ww_mutex_unlock(&mutex); ret = -EINVAL; goto out; } + ww_mutex_unlock(&mutex); ret = 0; out: - ww_mutex_unlock(&mutex); ww_acquire_fini(&ctx); return ret; } @@ -150,7 +178,7 @@ struct test_abba { struct ww_mutex b_mutex; struct completion a_ready; struct completion b_ready; - bool resolve; + bool resolve, trylock; int result; }; @@ -160,8 +188,13 @@ static void test_abba_work(struct work_struct *work) struct ww_acquire_ctx ctx; int err; - ww_acquire_init(&ctx, &ww_class); - ww_mutex_lock(&abba->b_mutex, &ctx); + ww_acquire_init_noinject(&ctx, &ww_class); + if (!abba->trylock) + ww_mutex_lock(&abba->b_mutex, &ctx); + else + WARN_ON(!ww_mutex_trylock(&abba->b_mutex, &ctx)); + + WARN_ON(READ_ONCE(abba->b_mutex.ctx) != &ctx); complete(&abba->b_ready); wait_for_completion(&abba->a_ready); @@ -181,7 +214,7 @@ static void test_abba_work(struct work_struct *work) abba->result = err; } -static int test_abba(bool resolve) +static int test_abba(bool trylock, bool resolve) { struct test_abba abba; struct ww_acquire_ctx ctx; @@ -192,12 +225,18 @@ static int test_abba(bool resolve) INIT_WORK_ONSTACK(&abba.work, test_abba_work); init_completion(&abba.a_ready); init_completion(&abba.b_ready); + abba.trylock = trylock; abba.resolve = resolve; schedule_work(&abba.work); - ww_acquire_init(&ctx, &ww_class); - ww_mutex_lock(&abba.a_mutex, &ctx); + ww_acquire_init_noinject(&ctx, &ww_class); + if (!trylock) + ww_mutex_lock(&abba.a_mutex, &ctx); + else + WARN_ON(!ww_mutex_trylock(&abba.a_mutex, &ctx)); + + WARN_ON(READ_ONCE(abba.a_mutex.ctx) != &ctx); complete(&abba.a_ready); wait_for_completion(&abba.b_ready); @@ -249,7 +288,7 @@ static void test_cycle_work(struct work_struct *work) struct ww_acquire_ctx ctx; int err, erra = 0; - ww_acquire_init(&ctx, &ww_class); + ww_acquire_init_noinject(&ctx, &ww_class); ww_mutex_lock(&cycle->a_mutex, &ctx); complete(cycle->a_signal); @@ -581,7 +620,9 @@ static int stress(int nlocks, int nthreads, unsigned int flags) static int __init test_ww_mutex_init(void) { int ncpus = num_online_cpus(); - int ret; + int ret, i; + + printk(KERN_INFO "Beginning ww mutex selftests\n"); wq = alloc_workqueue("test-ww_mutex", WQ_UNBOUND, 0); if (!wq) @@ -591,17 +632,19 @@ static int __init test_ww_mutex_init(void) if (ret) return ret; - ret = test_aa(); + ret = test_aa(false); if (ret) return ret; - ret = test_abba(false); + ret = test_aa(true); if (ret) return ret; - ret = test_abba(true); - if (ret) - return ret; + for (i = 0; i < 4; i++) { + ret = test_abba(i & 1, i & 2); + if (ret) + return ret; + } ret = test_cycle(ncpus); if (ret) @@ -619,6 +662,7 @@ static int __init test_ww_mutex_init(void) if (ret) return ret; + printk(KERN_INFO "All ww mutex selftests passed\n"); return 0; } diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c index 161108e5d2fe..71652e1c397c 100644 --- a/lib/locking-selftest.c +++ b/lib/locking-selftest.c @@ -258,7 +258,7 @@ static void init_shared_classes(void) #define WWAF(x) ww_acquire_fini(x) #define WWL(x, c) ww_mutex_lock(x, c) -#define WWT(x) ww_mutex_trylock(x) +#define WWT(x) ww_mutex_trylock(x, NULL) #define WWL1(x) ww_mutex_lock(x, NULL) #define WWU(x) ww_mutex_unlock(x) -- 2.33.0

7 18

[PATCH v2 0/2] Add support for querying hw info that UMDs need
by John.C.Harrison＠Intel.com 04 Nov '21

04 Nov '21

From: John Harrison <John.C.Harrison(a)Intel.com> Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. v2: Add a kerneldoc comment. Test-with: 20210915215558.2473428-2-John.C.Harrison(a)Intel.com UMD: https://github.com/intel/compute-runtime/pull/432/files UMD: https://github.com/intel/media-driver/pull/1239/files CC: Katarzyna Cencelewska <katarzyna.cencelewska(a)intel.com> CC: Tony Ye <tony.ye(a)intel.com> CC: Jason Ekstrand <jason.ekstrand(a)intel.com> Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 3 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 156 ++++++++++++++++++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 +++ include/uapi/drm/i915_drm.h | 1 + 10 files changed, 216 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1

3 7

[PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
by Michel Dänzer 04 Nov '21

04 Nov '21

From: Michel Dänzer <mdaenzer(a)redhat.com> This makes sure we don't hit the BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); in dma_buf_release, which could be triggered by user space closing the dma-buf file description while there are outstanding fence callbacks from dma_buf_poll. Cc: stable(a)vger.kernel.org Signed-off-by: Michel Dänzer <mdaenzer(a)redhat.com> --- drivers/dma-buf/dma-buf.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 6c520c9bd93c..ec25498a971f 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry) BUG_ON(dmabuf->vmapping_counter); /* - * Any fences that a dma-buf poll can wait on should be signaled - * before releasing dma-buf. This is the responsibility of each - * driver that uses the reservation objects. - * - * If you hit this BUG() it means someone dropped their ref to the - * dma-buf while still having pending operation to the buffer. + * If you hit this BUG() it could mean: + * * There's a file reference imbalance in dma_buf_poll / dma_buf_poll_cb or somewhere else + * * dmabuf->cb_in/out.active are non-0 despite no pending fence callback */ BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); @@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) { struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb; + struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll); unsigned long flags; spin_lock_irqsave(&dcb->poll->lock, flags); @@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) dcb->active = 0; spin_unlock_irqrestore(&dcb->poll->lock, flags); dma_fence_put(fence); + /* Paired with get_file in dma_buf_poll */ + fput(dmabuf->file); } static bool dma_buf_poll_shared(struct dma_resv *resv, @@ -278,6 +278,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) spin_unlock_irq(&dmabuf->poll.lock); if (events & EPOLLOUT) { + /* Paired with fput in dma_buf_poll_cb */ + get_file(dmabuf->file); + if (!dma_buf_poll_shared(resv, dcb) && !dma_buf_poll_excl(resv, dcb)) /* No callback queued, wake up any other waiters */ @@ -299,6 +302,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) spin_unlock_irq(&dmabuf->poll.lock); if (events & EPOLLIN) { + /* Paired with fput in dma_buf_poll_cb */ + get_file(dmabuf->file); + if (!dma_buf_poll_excl(resv, dcb)) /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); -- 2.32.0

4 7

[Bug 214029] New: [NAVI] Several memory leaks in amdgpu and ttm
by bugzilla-daemon＠bugzilla.kernel.org 04 Nov '21

04 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=214029 Bug ID: 214029 Summary: [NAVI] Several memory leaks in amdgpu and ttm Product: Drivers Version: 2.5 Kernel Version: 5.14-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org CC: daniel(a)ffwll.ch Regression: No Created attachment 298265 --> https://bugzilla.kernel.org/attachment.cgi?id=298265&action=edit kernel dmesg (kernel 5.14-rc5, AMD FX-8370) Getting this on kernel 5.14-rc5 with my Radeon RX 5500. unreferenced object 0xffff888169af1b40 (size 216): comm "lightdm-gtk-gre", pid 662, jiffies 4294902381 (age 13444.937s) hex dump (first 32 bytes): d0 1b af 69 81 88 ff ff 60 cb b9 c0 ff ff ff ff ...i....`....... 80 73 48 e1 13 00 00 00 58 7d c1 0b 00 c9 ff ff .sH.....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff888263377700 (size 72): comm "sdma0", pid 345, jiffies 4294902381 (age 13444.937s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ f2 a0 4c e1 13 00 00 00 58 28 9b c9 81 88 ff ff ..L.....X(...... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff88811314b9c0 (size 216): comm "mate-session-ch", pid 768, jiffies 4294905408 (age 13434.854s) hex dump (first 32 bytes): 50 ba 14 13 81 88 ff ff 60 cb b9 c0 ff ff ff ff P.......`....... dc 7a c1 3a 16 00 00 00 58 7d c1 0b 00 c9 ff ff .z.:....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff888167ffc340 (size 72): comm "sdma0", pid 345, jiffies 4294905408 (age 13434.854s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ ac b5 c5 3a 16 00 00 00 58 e4 a7 01 81 88 ff ff ...:....X....... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff888113b6d240 (size 216): comm "mate-screensave", pid 57770, jiffies 4295052030 (age 12946.214s) hex dump (first 32 bytes): d0 d2 b6 13 81 88 ff ff 60 cb b9 c0 ff ff ff ff ........`....... a2 85 ff 05 88 00 00 00 58 7d c1 0b 00 c9 ff ff ........X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff8881c85d6e80 (size 72): comm "sdma0", pid 345, jiffies 4295052030 (age 12946.217s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 0c a0 03 06 88 00 00 00 58 34 14 75 82 88 ff ff ........X4.u.... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff888119b78940 (size 216): comm "mate-screensave", pid 98610, jiffies 4295149755 (age 12620.510s) hex dump (first 32 bytes): d0 89 b7 19 81 88 ff ff 60 cb b9 c0 ff ff ff ff ........`....... 08 db 28 de d3 00 00 00 58 7d c1 0b 00 c9 ff ff ..(.....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff8882589af700 (size 72): comm "sdma0", pid 345, jiffies 4295149755 (age 12620.514s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 17 3c 2d de d3 00 00 00 58 b4 df 67 81 88 ff ff .<-.....X..g.... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8881274ccac0 (size 216): comm "mate-screensave", pid 98731, jiffies 4295150087 (age 12619.460s) hex dump (first 32 bytes): 50 cb 4c 27 81 88 ff ff 60 cb b9 c0 ff ff ff ff P.L'....`....... 7e bc 18 20 d4 00 00 00 58 7d c1 0b 00 c9 ff ff ~.. ....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff888255796940 (size 72): comm "sdma0", pid 345, jiffies 4295150087 (age 12619.464s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 0f be 1c 20 d4 00 00 00 58 70 a1 be 81 88 ff ff ... ....Xp...... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff88823ef75540 (size 216): comm "glxinfo", pid 173188, jiffies 4298442862 (age 1643.630s) hex dump (first 32 bytes): d0 55 f7 3e 82 88 ff ff 60 cb b9 c0 ff ff ff ff .U.>....`....... d7 bb 9c a7 cf 0a 00 00 58 7d c1 0b 00 c9 ff ff ........X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff88826dfee1c0 (size 72): comm "sdma0", pid 345, jiffies 4298442862 (age 1643.630s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 91 e3 a0 a7 cf 0a 00 00 58 04 01 14 81 88 ff ff ........X....... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff88823ef756c0 (size 216): comm "glxinfo:sh0", pid 173194, jiffies 4298442879 (age 1643.620s) hex dump (first 32 bytes): 50 57 f7 3e 82 88 ff ff 60 cb b9 c0 ff ff ff ff PW.>....`....... 3a 18 f8 aa cf 0a 00 00 58 7d c1 0b 00 c9 ff ff :.......X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff8882a950cb80 (size 72): comm "sdma0", pid 345, jiffies 4298442879 (age 1643.620s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 27 7b fc aa cf 0a 00 00 58 cc ec 19 81 88 ff ff '{......X....... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff888227171840 (size 216): comm "glxinfo", pid 173188, jiffies 4298442879 (age 1643.620s) hex dump (first 32 bytes): d0 18 17 27 82 88 ff ff 60 cb b9 c0 ff ff ff ff ...'....`....... f0 c7 0c ab cf 0a 00 00 58 7d c1 0b 00 c9 ff ff ........X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff8882a950cac0 (size 72): comm "sdma0", pid 345, jiffies 4298442879 (age 1643.620s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ f1 fe 10 ab cf 0a 00 00 58 9c ec 19 81 88 ff ff ........X....... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff88816aaca940 (size 216): comm "glxinfo", pid 173247, jiffies 4298445099 (age 1636.294s) hex dump (first 32 bytes): d0 a9 ac 6a 81 88 ff ff 60 cb b9 c0 ff ff ff ff ...j....`....... 4d 52 2f 64 d1 0a 00 00 58 7d c1 0b 00 c9 ff ff MR/d....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff88825fe8d700 (size 72): comm "sdma0", pid 345, jiffies 4298445099 (age 1636.294s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 63 72 33 64 d1 0a 00 00 58 64 7b 47 81 88 ff ff cr3d....Xd{G.... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8881433c2940 (size 216): comm "glxinfo:sh0", pid 173253, jiffies 4298445116 (age 1636.240s) hex dump (first 32 bytes): d0 29 3c 43 81 88 ff ff 60 cb b9 c0 ff ff ff ff .)<C....`....... 1b 8a 79 67 d1 0a 00 00 58 7d c1 0b 00 c9 ff ff ..yg....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff88825fe8d580 (size 72): comm "sdma0", pid 345, jiffies 4298445116 (age 1636.240s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ 99 20 7e 67 d1 0a 00 00 58 a8 28 8b 82 88 ff ff . ~g....X.(..... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8881433c24c0 (size 216): comm "glxinfo", pid 173247, jiffies 4298445116 (age 1636.314s) hex dump (first 32 bytes): 50 25 3c 43 81 88 ff ff 60 cb b9 c0 ff ff ff ff P%<C....`....... 57 37 94 67 d1 0a 00 00 58 7d c1 0b 00 c9 ff ff W7.g....X}...... backtrace: [<ffffffffc0b9914f>] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [<ffffffffc0b944de>] drm_sched_job_init+0x10e/0x240 [gpu_sched] [<ffffffffc138dd37>] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [<ffffffffc0f7ae6e>] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [<ffffffffc0f7b6ca>] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [<ffffffffc0f7ce06>] amdgpu_bo_move+0x356/0x2180 [amdgpu] [<ffffffffc0a79897>] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [<ffffffffc0a7d297>] ttm_bo_validate+0x2c7/0x450 [ttm] [<ffffffffc0f83444>] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [<ffffffffc0f93313>] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [<ffffffffab55c3b3>] __do_fault+0xf3/0x3e0 [<ffffffffab56e5ab>] __handle_mm_fault+0x1bcb/0x2ac0 [<ffffffffab56f5ca>] handle_mm_fault+0x12a/0x490 [<ffffffffab0908b9>] do_user_addr_fault+0x259/0xb70 [<ffffffffac7b6935>] exc_page_fault+0x55/0xb0 [<ffffffffac800acb>] asm_exc_page_fault+0x1b/0x20 unreferenced object 0xffff8881dbf6b340 (size 72): comm "sdma0", pid 345, jiffies 4298445116 (age 1636.314s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i............ f9 60 98 67 d1 0a 00 00 58 b4 28 8b 82 88 ff ff .`.g....X.(..... backtrace: [<ffffffffc0f70521>] amdgpu_fence_emit+0x91/0x790 [amdgpu] [<ffffffffc0fdd4bb>] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [<ffffffffc138d09e>] amdgpu_job_run+0x35e/0x790 [amdgpu] [<ffffffffc0b9792e>] drm_sched_main+0x64e/0xc60 [gpu_sched] [<ffffffffab12fda2>] kthread+0x342/0x410 [<ffffffffab0030d2>] ret_from_fork+0x22/0x30 $ inxi -bZ System: Kernel: 5.14.0-rc5-bdver2 x86_64 bits: 64 Desktop: MATE 1.24.1 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop System: Gigabyte product: N/A v: N/A serial: <superuser/root required> Mobo: Gigabyte model: 970-GAMING v: x.x serial: <superuser/root required> UEFI: American Megatrends v: F2 date: 04/06/2016 CPU: Info: 8-Core AMD FX-8370 [MCP] speed: 1727 MHz min/max: 1400/4000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.11 driver: amdgpu,ati unloaded: fbdev,modesetting,radeon resolution: 1920x1080~60Hz OpenGL: renderer: Radeon RX 5500 XT (NAVI14 DRM 3.42.0 5.14.0-rc5-bdver2 LLVM 12.0.1) v: 4.6 Mesa 21.1.4 Network: Device-1: Qualcomm Atheros Killer E2400 Gigabit Ethernet driver: alx $ lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge (rev 02) 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU) 00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) 00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 2) 00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40) 00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) 00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 5 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c5) 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] (rev c5) 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio 04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) 05:00.0 Non-Volatile memory controller: Shenzhen Longsys Electronics Co., Ltd. Device 2263 (rev 03) 06:00.0 USB controller: ASMedia Technology Inc. ASM1143 USB 3.1 Host Controller 08:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10) # lspci -vv -s 03:00.0 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] (rev c5) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Navi 14 [Radeon RX 5500/5500M / Pro 5500M] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 65 IOMMU group: 17 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=2M] Region 4: I/O ports at e000 [size=256] Region 5: Memory at fe500000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [64] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 16GT/s (ok), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit+ 64bit+ 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS- LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee01004 Data: 0025 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [200 v1] Physical Resizable BAR BAR 0: current size: 256MB, supported: 256MB 512MB 1GB 2GB 4GB 8GB BAR 2: current size: 2MB, supported: 2MB 4MB 8MB 16MB 32MB 64MB 128MB 256MB Capabilities: [240 v1] Power Budgeting <?> Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [2a0 v1] Access Control Services ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans- ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans- Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00000100, Page Request Allocation: 00000000 Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec+ Priv+, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Capabilities: [320 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [400 v1] Data Link Feature <?> Capabilities: [410 v1] Physical Layer 16.0 GT/s <?> Capabilities: [440 v1] Lane Margining at the Receiver <?> Kernel driver in use: amdgpu Kernel modules: amdgpu -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 29

[PATCH v11 0/4] Add MIPI rx DPI support
by Xin Ji 04 Nov '21

04 Nov '21

Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v11 version, rebase all patches on the latest code. Any mistakes, please let me know, I'll fix it in the next series. Change history: v11: Fix Rob Herring comment - Move swing register description in property. - Remove additional property. v10: Fix Rob Herring and Laurent Pinchart comments - Add more description about lane swing configuration in commit message. v9: Fix Neil Amstrong comment - use macro define 'V4L2_FWNODE_BUS_TYPE_PARALLEL' instead of fixing value. v8: Fix Laurent Pinchart comment - Expand the commit message. v7: - Rebase DT on the latest branch 'drm-misc-next'. - Remove HDCP patch. v6: Fix kernel robot compile warning v5: Fix Rob Herring, Hsin-Yi, Robert Foss comments - Rebase code on the branch 'drm-misc-next', refer video-interfaces.yaml - Seprate HDCP function to a new patch - Fix driver not correctly get 'bus-type' 'data-lanes' - Add audio HDMI codec function support v4: Fix Rob Herring comment - Rebase code on the branch 'drm-misc-next' - Change 'analogix,hdcp-support' type to boolean v3: Fix Rob Herring, Dan Carpenter, Nicolas comment - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (4): dt-bindings:drm/bridge:anx7625:add vendor define drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature drm/bridge: anx7625: add HDMI audio function .../display/bridge/analogix,anx7625.yaml | 65 ++- drivers/gpu/drm/bridge/analogix/anx7625.c | 458 ++++++++++++++++-- drivers/gpu/drm/bridge/analogix/anx7625.h | 23 +- 3 files changed, 491 insertions(+), 55 deletions(-) -- 2.25.1

4 14

[PATCH] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Anand K Mistry 03 Nov '21

03 Nov '21

drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> --- drivers/gpu/drm/drm_prime.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 2a54f86856af..e1854fd24bb0 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -719,11 +719,13 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) if (obj->funcs && obj->funcs->mmap) { vma->vm_ops = obj->funcs->vm_ops; + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.33.0.800.g4c38ced690-goog

3 3

← Newer
1
...
7
8
9
10
11
12
13
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021