dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

5.14.9: warning at drivers/gpu/drm/ttm/ttm_bo.c:409 with amdgpu
by Frederik Himpe 12 Oct '21

12 Oct '21

Hi, With Linux 5.14 kernel series, I often get this warning: okt 12 16:36:05 piranha kernel: ------------[ cut here ]------------ okt 12 16:36:05 piranha kernel: WARNING: CPU: 11 PID: 1 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x2d1/0x300 [ttm] okt 12 16:36:05 piranha kernel: Modules linked in: xt_recent ip6t_REJECT nf_reject_ipv6 xt_multiport xt_comment ip6_tables xt_hashlimit xt_mark xt_CT xt_NFLOG nfnetlink_log xt_LOG nf_log_syslog nf_conntrack_tftp nf_conntrack_sip nf_connt> okt 12 16:36:05 piranha kernel: gpu_sched radeon ppdev snd_hda_codec drm_ttm_helper ttm aesni_intel snd_hda_core evdev crypto_simd snd_hwdep drm_kms_helper snd_pcm cryptd wmi_bmof pcspkr rapl efi_pstore snd_timer bfq cec ccp snd rc_core> okt 12 16:36:05 piranha kernel: CPU: 11 PID: 1 Comm: systemd Not tainted 5.14.0-2-amd64 #1 Debian 5.14.9-2 okt 12 16:36:05 piranha kernel: Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 PC MATE (MS-7A34), BIOS A.J0 01/23/2019 okt 12 16:36:05 piranha kernel: RIP: 0010:ttm_bo_release+0x2d1/0x300 [ttm] okt 12 16:36:05 piranha kernel: Code: 65 23 00 00 e9 83 fd ff ff e8 3b 0e 31 ce e9 bc fd ff ff 49 8b 7e 98 b9 4c 1d 00 00 31 d2 be 01 00 00 00 e8 a1 32 31 ce eb a2 <0f> 0b e9 50 fd ff ff e8 d3 13 31 ce e9 fd fe ff ff be 03 00 00 00 okt 12 16:36:05 piranha kernel: RSP: 0018:ffffa84d8003be18 EFLAGS: 00010202 okt 12 16:36:05 piranha kernel: RAX: 0000000000000001 RBX: ffffa84d8003be60 RCX: 0000000000000000 okt 12 16:36:05 piranha kernel: RDX: 0000000000000001 RSI: ffff95e4abf95b00 RDI: ffff95e482cde9b8 okt 12 16:36:05 piranha kernel: RBP: ffff95e486f05288 R08: ffff95e482cde9b8 R09: 0000000000000064 okt 12 16:36:05 piranha kernel: R10: 0000000000000010 R11: ffff95e4f8c23a10 R12: ffff95e4d28f2a18 okt 12 16:36:05 piranha kernel: R13: ffff95e482cde858 R14: ffff95e482cde9b8 R15: 0000000000000000 okt 12 16:36:05 piranha kernel: FS: 00007f269dee6900(0000) GS:ffff95e78eec0000(0000) knlGS:0000000000000000 okt 12 16:36:05 piranha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 okt 12 16:36:05 piranha kernel: CR2: 0000563fbde29530 CR3: 00000001045ee000 CR4: 00000000003506e0 okt 12 16:36:05 piranha kernel: Call Trace: okt 12 16:36:05 piranha kernel: amdgpu_bo_unref+0x1a/0x30 [amdgpu] okt 12 16:36:05 piranha kernel: amdgpu_gem_object_free+0x30/0x50 [amdgpu] okt 12 16:36:05 piranha kernel: drm_gem_dmabuf_release+0x36/0x50 [drm] okt 12 16:36:05 piranha kernel: dma_buf_release+0x3a/0x80 okt 12 16:36:05 piranha kernel: __dentry_kill+0x106/0x180 okt 12 16:36:05 piranha kernel: __fput+0xe3/0x240 okt 12 16:36:05 piranha kernel: task_work_run+0x65/0xa0 okt 12 16:36:05 piranha kernel: exit_to_user_mode_prepare+0x173/0x180 okt 12 16:36:05 piranha kernel: syscall_exit_to_user_mode+0x23/0x40 okt 12 16:36:05 piranha kernel: ? __x64_sys_close+0xe/0x40 okt 12 16:36:05 piranha kernel: do_syscall_64+0x48/0xc0 okt 12 16:36:05 piranha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae okt 12 16:36:05 piranha kernel: RIP: 0033:0x7f269e79b8bb okt 12 16:36:05 piranha kernel: Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 83 fb ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 e1 fb ff ff 8b 44 okt 12 16:36:05 piranha kernel: RSP: 002b:00007fffc3c46910 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 okt 12 16:36:05 piranha kernel: RAX: 0000000000000000 RBX: 00007f269dee66d0 RCX: 00007f269e79b8bb okt 12 16:36:05 piranha kernel: RDX: 0000000000000002 RSI: 0000000563fbdd73 RDI: 0000000000000019 okt 12 16:36:05 piranha kernel: RBP: 0000000000000019 R08: 0000000000000000 R09: 0000563fbbf5f8ca okt 12 16:36:05 piranha kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 okt 12 16:36:05 piranha kernel: R13: 0000000000000000 R14: 0000563fbbf61108 R15: 0000563fbde422a0 okt 12 16:36:05 piranha kernel: ---[ end trace 807bb557a05dc0c6 ]--- It seems to happen often at shutdown but also shortly after boot. I'm also experiencing frequent hangs on this system, but I don't know whether these are related to this warning. The graphics card is: 1c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP] [1002:6819] and I'm using these boot options: radeon.si_support=0 amdgpu.si_support=1 This seems to be the same problem as reported here for 5.15-rc4: https://bugzilla.kernel.org/show_bug.cgi?id=214621 -- Frederik Himpe <frederik(a)frehi.be>

1 0

[PATCH v5 0/8] drm/omap: Add virtual-planes support
by Neil Armstrong 12 Oct '21

12 Oct '21

This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. This patch series adds virtual-plane support to omapdrm driver to allow the use of display wider than 2048 pixels. In order to do so we introduce the concept of hw_overlay which can then be dynamically allocated to a plane. When the requested output width exceed what be supported by one overlay a second is then allocated if possible to handle display wider then 2048. This series replaces an earlier series which was DT based and using statically allocated resources. This implementation is inspired from the work done in msm/disp/mdp5 driver. Changes since v4 at [1]: - rebased on v5.15-rc2 - adapted to drm_atomic_get_new/old_plane_state() - tested on Beagle-x15 - checked for non-regression on Beagle-x15 - removed unused "state" variable in omap_global_state [1] https://lore.kernel.org/all/20181012201703.29065-1-bparrot@ti.com/ Benoit Parrot (8): drm/omap: Add ability to check if requested plane modes can be supported drm/omap: Add ovl checking funcs to dispc_ops drm/omap: introduce omap_hw_overlay drm/omap: omap_plane: subclass drm_plane_state drm/omap: Add global state as a private atomic object drm/omap: dynamically assign hw overlays to planes drm/omap: add plane_atomic_print_state support drm/omap: Add a 'right overlay' to plane state drivers/gpu/drm/omapdrm/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/dispc.c | 31 +- drivers/gpu/drm/omapdrm/dss/dss.h | 5 + drivers/gpu/drm/omapdrm/omap_drv.c | 189 ++++++++++++- drivers/gpu/drm/omapdrm/omap_drv.h | 28 ++ drivers/gpu/drm/omapdrm/omap_fb.c | 33 ++- drivers/gpu/drm/omapdrm/omap_fb.h | 4 +- drivers/gpu/drm/omapdrm/omap_overlay.c | 254 +++++++++++++++++ drivers/gpu/drm/omapdrm/omap_overlay.h | 41 +++ drivers/gpu/drm/omapdrm/omap_plane.c | 375 +++++++++++++++++++++---- drivers/gpu/drm/omapdrm/omap_plane.h | 1 + 11 files changed, 903 insertions(+), 59 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.c create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.h -- 2.25.1

2 26

[PATCH][next] drm/i915: Fix dereference of pointer backup before it is null checked
by Colin King 12 Oct '21

12 Oct '21

From: Colin Ian King <colin.king(a)canonical.com> The assignment of pointer backup_bo dereferences pointer backup before backup is null checked, this could lead to a null pointer dereference issue. Fix this by only assigning backup_bo after backup has been null checked. Addresses-Coverity: ("Dereference before null check") Fixes: c56ce9565374 ("drm/i915 Implement LMEM backup and restore for suspend / resume") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c index 3b6d14b5c604..4ec6c557083a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c @@ -149,7 +149,7 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region *apply, struct i915_gem_ttm_pm_apply *pm_apply = container_of(apply, typeof(*pm_apply), base); struct drm_i915_gem_object *backup = obj->ttm.backup; - struct ttm_buffer_object *backup_bo = i915_gem_to_ttm(backup); + struct ttm_buffer_object *backup_bo; struct ttm_operation_ctx ctx = {}; int err; @@ -163,6 +163,8 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region *apply, if (err) return err; + backup_bo = i915_gem_to_ttm(backup); + /* Content may have been swapped. */ err = ttm_tt_populate(backup_bo->bdev, backup_bo->ttm, &ctx); if (!err) { -- 2.32.0

3 2

[PATCH v2 00/10] drm/gma500: Refactor GEM code
by Thomas Zimmermann 12 Oct '21

12 Oct '21

Bring GEM code up to current standards and untangle the connection to GTT helpers. The allocation and pinning helpers for struct gtt_range are located in the GTT code, but actually part of the GEM implementation. The patchset moves them to GEM code and refactors much of the implementation. Most of the GTT code is then independend from the struct gtt_range, while the GEM code does not contain GTT management. In addition to internal refiactoring, patches 2 to 4 update the rest of the driver to use the GEM interfaces for object allocation and release. Finally, rename struct gtt_range to struct psb_gem_object to designate it as a 'real' GEM object. Future work: with the GEM and GTT code separated, future patchsets can implement on-demand release of GTT entries, or remove the perma-mapping of stolen memory. Dma-buf support might also be added. Tested on Atom N2800 hardware. v2: * keep docs about GTT locking * release mutex in pin error path Thomas Zimmermann (10): drm/gma500: Move helpers for struct gtt_range from gtt.c to gem.c drm/gma500: Use to_gtt_range() everywhere drm/gma500: Reimplement psb_gem_create() drm/gma500: Allocate GTT ranges in stolen memory with psb_gem_create() drm/gma500: Rename psb_gtt_{pin,unpin}() to psb_gem_{pin,unpin}() drm/gma500: Inline psb_gtt_attach_pages() and psb_gtt_detach_pages() drm/gma500: Inline psb_gtt_{alloc,free}_range() into rsp callers drm/gma500: Set page-caching flags in GEM pin/unpin drm/gma500: Rewrite GTT page insert/remove without struct gtt_range drm/gma500: Rename struct gtt_range to struct psb_gem_object drivers/gpu/drm/gma500/framebuffer.c | 52 +--- drivers/gpu/drm/gma500/gem.c | 234 +++++++++++---- drivers/gpu/drm/gma500/gem.h | 28 +- drivers/gpu/drm/gma500/gma_display.c | 51 ++-- drivers/gpu/drm/gma500/gtt.c | 320 ++++----------------- drivers/gpu/drm/gma500/gtt.h | 29 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 3 +- drivers/gpu/drm/gma500/psb_intel_display.c | 17 +- drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- 9 files changed, 317 insertions(+), 419 deletions(-) -- 2.33.0

2 15

[RFC PATCH 0/2] EFA dmabuf memory regions
by Gal Pressman 12 Oct '21

12 Oct '21

Hey all, This is a followup to my previous RFC [1], which now makes use of the dynamic attachment API implemented in the RDMA subsystem, but calls dma_buf_pin() in order to make sure that the move_notify callback will not be used, as suggested by Christian. As explained in the previous RFC, move_notify requires the RDMA device to support on-demand-paging (ODP) which is not common on most devices (only supported by mlx5). While the dynamic requirement makes sense for certain GPUs, some devices (such as habanalabs) have device memory that is always "pinned" and do not need/use the move_notify operation. The first patch changes the dmabuf documentation to make it clear that pinning does not necessarily mean the memory must be moved to system memory, it is up to the exporter to decide. The motivation of this RFC is to use habanalabs as the dmabuf exporter, and EFA as the importer to allow for peer2peer access through libibverbs. [1] https://lore.kernel.org/linux-rdma/20210818074352.29950-1-galpress@amazon.c… Thanks Gal Pressman (2): dma-buf: Fix pin callback comment RDMA/efa: Add support for dmabuf memory regions drivers/infiniband/hw/efa/efa.h | 4 + drivers/infiniband/hw/efa/efa_main.c | 1 + drivers/infiniband/hw/efa/efa_verbs.c | 166 +++++++++++++++++++++----- include/linux/dma-buf.h | 4 +- 4 files changed, 142 insertions(+), 33 deletions(-) -- 2.33.0

3 8

linux-next: Fixes tag needs some work in the drm-fixes tree
by Stephen Rothwell 12 Oct '21

12 Oct '21

Hi all, In commit 654e9c18dfab ("drm/msm: Fix crash on dev file close") Fixes tag Fixes: 86c2a0f000c1 drm/msm: ("Small submitqueue creation cleanup") has these problem(s): - Subject does not match target commit subject Just use git log -1 --format='Fixes: %h ("%s")' -- Cheers, Stephen Rothwell

1 0

[PATCH v3 0/5] mxsfb/nwl/panels: media bus format fixes
by Guido Günther 12 Oct '21

12 Oct '21

commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if present") added bus format probing to mxsfb this exposed several issues in the display stack as used on the Librem 5: The nwl bridge and the panels didn't bother to set any media bus formats and in that case mxsfb would not pick a reasonable default. This series aims to fix this. This series includes the patch from https://lore.kernel.org/dri-devel/YVLYh%2FSgBritG%2FRJ@qwark.sigxcpu.org/ with a `dev_warn` added. The patches are against 5.15-rc3. I've marked a single patch with a 'fixes' which is enough to unbreak the display stack in 5.15. All patches of this series can be applied independently. Changes from v1: - Review comment by Marek Vasut https://lore.kernel.org/dri-devel/67e6056a-6157-795d-908d-d65cc803c03d@denx… Improve warning message - Move mxsfb patches to the end of the queue and the actual nwl fix to the front. Changes from v2: - Review comments by Lucas Stach https://lore.kernel.org/dri-devel/cover.1633332399.git.agx@sigxcpu.org/T/#m… Drop fixes tag from mxsfb driver and tweak commit message - Add Reviewed-by from Lucas https://lore.kernel.org/dri-devel/cover.1633332399.git.agx@sigxcpu.org/T/#m… https://lore.kernel.org/dri-devel/cover.1633332399.git.agx@sigxcpu.org/T/#m… https://lore.kernel.org/dri-devel/cover.1633332399.git.agx@sigxcpu.org/T/#m… - Add Reviewd-by from Rober Foss https://lore.kernel.org/dri-devel/CAG3jFyteqcPNZqrFsggCrnpDfsGGQvibfHBezW+1… Guido Günther (5): drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts drm/panel: mantix: Add media bus format drm/panel: st7703: Add media bus format drm: mxsfb: Print failed bus format in hex drm: mxsfb: Set fallback bus format when the bridge doesn't provide one drivers/gpu/drm/bridge/nwl-dsi.c | 35 +++++++++++++++++++ drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 ++++- .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +++++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +++++ 4 files changed, 59 insertions(+), 1 deletion(-) -- 2.33.0

4 10

[PATCH] drm/i915/gvt: clean up kernel-doc in gtt.c
by Randy Dunlap 12 Oct '21

12 Oct '21

Fix kernel-doc warnings in gtt.c: gtt.c:1152: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Check if can do 2M page gtt.c:1152: warning: missing initial short description on line: * Check if can do 2M page gtt.c:2209: warning: expecting prototype for intel_vgpu_emulate_gtt_mmio_read(). Prototype was for intel_vgpu_emulate_ggtt_mmio_read() instead Fixes: a752b070a678 ("drm/i915/gvt: Fix function comment doc errors") Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Zhenyu Wang <zhenyuw(a)linux.intel.com> Cc: Zhi Wang <zhi.a.wang(a)intel.com> Cc: Colin Xu <colin.xu(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: intel-gvt-dev(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20211001.orig/drivers/gpu/drm/i915/gvt/gtt.c +++ linux-next-20211001/drivers/gpu/drm/i915/gvt/gtt.c @@ -1148,7 +1148,7 @@ static inline void ppgtt_generate_shadow ops->set_pfn(se, s->shadow_page.mfn); } -/** +/* * Check if can do 2M page * @vgpu: target vgpu * @entry: target pfn's gtt entry @@ -2193,7 +2193,7 @@ static int emulate_ggtt_mmio_read(struct } /** - * intel_vgpu_emulate_gtt_mmio_read - emulate GTT MMIO register read + * intel_vgpu_emulate_ggtt_mmio_read - emulate GTT MMIO register read * @vgpu: a vGPU * @off: register offset * @p_data: data will be returned to guest

2 1

[PATCH 1/4] dri: do not check for NULL debugfs dentry
by Nirmoy Das 12 Oct '21

12 Oct '21

Debugfs APIs returns encoded error on failure instead of NULL and for drm primary/minor debugfs directories, we save the returned value in the dentry pointer and pass it on to drm drivers to further create debugfs files/directories. Error conditions are handled by debugfs APIs, so no need to check for NULL, as saved dentry pointers will either contain a valid pointer or an error code. CC: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> CC: Maxime Ripard <mripard(a)kernel.org> CC: Thomas Zimmermann <tzimmermann(a)suse.de> CC: David Airlie <airlied(a)linux.ie> CC: Daniel Vetter <daniel(a)ffwll.ch> Signed-off-by: Nirmoy Das <nirmoy.das(a)amd.com> --- drivers/gpu/drm/drm_debugfs.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index b0a826489488..0073854a4383 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -272,9 +272,6 @@ static void drm_debugfs_remove_all_files(struct drm_minor *minor) void drm_debugfs_cleanup(struct drm_minor *minor) { - if (!minor->debugfs_root) - return; - drm_debugfs_remove_all_files(minor); debugfs_remove_recursive(minor->debugfs_root); @@ -419,9 +416,6 @@ void drm_debugfs_connector_add(struct drm_connector *connector) struct drm_minor *minor = connector->dev->primary; struct dentry *root; - if (!minor->debugfs_root) - return; - root = debugfs_create_dir(connector->name, minor->debugfs_root); connector->debugfs_entry = root; @@ -440,9 +434,6 @@ void drm_debugfs_connector_add(struct drm_connector *connector) void drm_debugfs_connector_remove(struct drm_connector *connector) { - if (!connector->debugfs_entry) - return; - debugfs_remove_recursive(connector->debugfs_entry); connector->debugfs_entry = NULL; -- 2.32.0

4 8

[PATCH] lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()
by Vlastimil Babka 12 Oct '21

12 Oct '21

Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated from memblock, even if stack depot ends up not actually used. The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit. This is fine for use-cases such as KASAN which is also a config option and has overhead on its own. But it's an issue for functionality that has to be actually enabled on boot (page_owner) or depends on hardware (GPU drivers) and thus the memory might be wasted. This was raised as an issue when trying to add stackdepot support for SLUB's debug object tracking functionality. It's common to build kernels with CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or create specific kmem caches with debugging for testing purposes. It would thus be more efficient if stackdepot's table was allocated only when actually going to be used. This patch thus makes the allocation (and whole stack_depot_init() call) optional: - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN select this flag. - Other users have to call stack_depot_init() as part of their own init when it's determined that stack depot will actually be used. This may depend on both config and runtime conditions. Convert current users which are page_owner and several in the DRM subsystem. Same will be done for SLUB later. - Because the init might now be called after the boot-time memblock allocation has given all memory to the buddy allocator, change stack_depot_init() to allocate stack_table with kvmalloc() when memblock is no longer available. Also handle allocation failure by disabling stackdepot (could have theoretically happened even with memblock allocation previously), and don't unnecessarily align the memblock allocation to its own size anymore. [1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCv… Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Marco Elver <elver(a)google.com> Cc: Vijayanand Jitta <vjitta(a)codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Oliver Glitta <glittao(a)gmail.com> Cc: Imran Khan <imran.f.khan(a)oracle.com> --- Hi, I'd appreciate review of the DRM parts - namely that I've got correctly that stack_depot_init() is called from the proper init functions and iff stack_depot_save() is going to be used later. Thanks! drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/drm_mm.c | 4 ++++ drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++ include/linux/stackdepot.h | 19 ++++++++------- init/main.c | 3 ++- lib/Kconfig | 3 +++ lib/Kconfig.kasan | 1 + lib/stackdepot.c | 32 +++++++++++++++++++++---- mm/page_owner.c | 2 ++ 9 files changed, 53 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 2d1adab9e360..bbe972d59dae 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -5490,6 +5490,7 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr, mutex_init(&mgr->probe_lock); #if IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS) mutex_init(&mgr->topology_ref_history_lock); + stack_depot_init(); #endif INIT_LIST_HEAD(&mgr->tx_msg_downq); INIT_LIST_HEAD(&mgr->destroy_port_list); diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 7d1c578388d3..8257f9d4f619 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -980,6 +980,10 @@ void drm_mm_init(struct drm_mm *mm, u64 start, u64 size) add_hole(&mm->head_node); mm->scan_active = 0; + +#ifdef CONFIG_DRM_DEBUG_MM + stack_depot_init(); +#endif } EXPORT_SYMBOL(drm_mm_init); diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 0d85f3c5c526..806c32ab410b 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -68,6 +68,9 @@ static noinline depot_stack_handle_t __save_depot_stack(void) static void init_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm) { spin_lock_init(&rpm->debug.lock); + + if (rpm->available) + stack_depot_init(); } static noinline depot_stack_handle_t diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h index c34b55a6e554..60ba99a43745 100644 --- a/include/linux/stackdepot.h +++ b/include/linux/stackdepot.h @@ -15,6 +15,16 @@ typedef u32 depot_stack_handle_t; +/* + * Every user of stack depot has to call this during its own init when it's + * decided that it will be calling stack_depot_save() later. + * + * The alternative is to select STACKDEPOT_ALWAYS_INIT to have stack depot + * enabled as part of mm_init(), for subsystems where it's known at compile time + * that stack depot will be used. + */ +int stack_depot_init(void); + depot_stack_handle_t __stack_depot_save(unsigned long *entries, unsigned int nr_entries, gfp_t gfp_flags, bool can_alloc); @@ -30,13 +40,4 @@ int stack_depot_snprint(depot_stack_handle_t handle, char *buf, size_t size, void stack_depot_print(depot_stack_handle_t stack); -#ifdef CONFIG_STACKDEPOT -int stack_depot_init(void); -#else -static inline int stack_depot_init(void) -{ - return 0; -} -#endif /* CONFIG_STACKDEPOT */ - #endif diff --git a/init/main.c b/init/main.c index ee4d3e1b3eb9..b6a5833d98f5 100644 --- a/init/main.c +++ b/init/main.c @@ -844,7 +844,8 @@ static void __init mm_init(void) init_mem_debugging_and_hardening(); kfence_alloc_pool(); report_meminit(); - stack_depot_init(); + if (IS_ENABLED(CONFIG_STACKDEPOT_ALWAYS_INIT)) + stack_depot_init(); mem_init(); mem_init_print_info(); /* page_owner must be initialized after buddy is ready */ diff --git a/lib/Kconfig b/lib/Kconfig index 5e7165e6a346..df6bcf0a4cc3 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -671,6 +671,9 @@ config STACKDEPOT bool select STACKTRACE +config STACKDEPOT_ALWAYS_INIT + bool + config STACK_HASH_ORDER int "stack depot hash size (12 => 4KB, 20 => 1024KB)" range 12 20 diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index cdc842d090db..695deb603c66 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -39,6 +39,7 @@ menuconfig KASAN HAVE_ARCH_KASAN_HW_TAGS depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) select STACKDEPOT + select STACKDEPOT_ALWAYS_INIT help Enables KASAN (KernelAddressSANitizer) - runtime memory debugger, designed to find out-of-bounds accesses and use-after-free bugs. diff --git a/lib/stackdepot.c b/lib/stackdepot.c index b437ae79aca1..a4f449ccd0dc 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -23,6 +23,7 @@ #include <linux/jhash.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/mutex.h> #include <linux/percpu.h> #include <linux/printk.h> #include <linux/slab.h> @@ -145,6 +146,7 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc) #define STACK_HASH_MASK (STACK_HASH_SIZE - 1) #define STACK_HASH_SEED 0x9747b28c +DEFINE_MUTEX(stack_depot_init_mutex); static bool stack_depot_disable; static struct stack_record **stack_table; @@ -161,18 +163,38 @@ static int __init is_stack_depot_disabled(char *str) } early_param("stack_depot_disable", is_stack_depot_disabled); -int __init stack_depot_init(void) +/* + * __ref because of memblock_alloc(), which will not be actually called after + * the __init code is gone + */ +__ref int stack_depot_init(void) { - if (!stack_depot_disable) { + mutex_lock(&stack_depot_init_mutex); + if (!stack_depot_disable && stack_table == NULL) { size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *)); int i; - stack_table = memblock_alloc(size, size); - for (i = 0; i < STACK_HASH_SIZE; i++) - stack_table[i] = NULL; + if (slab_is_available()) { + pr_info("Stack Depot allocating hash table with kvmalloc\n"); + stack_table = kvmalloc(size, GFP_KERNEL); + } else { + pr_info("Stack Depot allocating hash table with memblock_alloc\n"); + stack_table = memblock_alloc(size, SMP_CACHE_BYTES); + } + if (stack_table) { + for (i = 0; i < STACK_HASH_SIZE; i++) + stack_table[i] = NULL; + } else { + pr_err("Stack Depot failed hash table allocationg, disabling\n"); + stack_depot_disable = true; + mutex_unlock(&stack_depot_init_mutex); + return -ENOMEM; + } } + mutex_unlock(&stack_depot_init_mutex); return 0; } +EXPORT_SYMBOL_GPL(stack_depot_init); /* Calculate hash for a stack */ static inline u32 hash_stack(unsigned long *entries, unsigned int size) diff --git a/mm/page_owner.c b/mm/page_owner.c index a83f546c06b5..a48607b51a97 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -80,6 +80,8 @@ static void init_page_owner(void) if (!page_owner_enabled) return; + stack_depot_init(); + register_dummy_stack(); register_failure_stack(); register_early_stack(); -- 2.33.0

3 5

← Newer
1
...
57
58
59
60
61
62
63
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021