dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH v2 00/63] Introduce strict memcpy() bounds checking
by Kees Cook 24 Nov '21

24 Nov '21

Hi, This patch series (based on next-20210816) implements stricter (no struct member overflows) bounds checking for memcpy(), memmove(), and memset() under CONFIG_FORTIFY_SOURCE. To quote a later patch in the series: tl;dr: In order to eliminate a large class of common buffer overflow flaws that continue to persist in the kernel, have memcpy() (under CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct member when they have a known size. This would have caught all of the memcpy()-related buffer write overflow flaws identified in at least the last three years. As this series introduces various helpers and performs several phases of treewide cleanups, I'm expecting to carry this series in my tree, so I'd love to get some Reviews and Acks. Given the size, I've mostly aimed this series at various mailing lists, otherwise the CC size got really big. :) I have separated a few things off of this submission, as things continue to grow: - run-time bounds checking (which now has a better solution for unknown bounds besides "oh well") - __alloc_size enablement (sent separately[1]) - -Warray-bounds enablement (several cleanups have been sent) The remaining portions (here) haven't seen as much change, so I think it's better to get these compile-time portions landed first -- they're big enough. My intention is to put this in -next soon via my "overflow" tree, assuming people are happy with it. :) Another random thing of note, I'm using the "Enhanced-by:" tag to mean "this was improved by...", inspired by the existing "Fixed-by:" tag (for "folded fixes"). "Fixed-by:" seemed inaccurate (it wasn't broken; it is just better now), and "Suggested-by:" seemed too nebulous (what was suggested?). Thanks! -Kees [1] https://lore.kernel.org/lkml/20210818050841.2226600-1-keescook@chromium.org/ v2: - fix CC_IS_CLANG typo (nathan) - bug.h hunk moved later (ndesaulnier) - various commit log typos (ndesaulnier) - omap3isp: fix read source (gustavo) - struct_group can be variadic (rasmus) - add struct_group_tagged (dan williams) - move raw __struct_group() to UAPI (gregkh, dan vetter) - ibmvscsi: add BUILD_BUG_ON() size checks - net: use memset_after() instead of struct_group() (jakob) - swap some memset_after() to memset_startat() for readability - add missing __NO_FORTIFY to arm boot stub (lkp) - powerpc signal32 struct_group() added (lkp) - powerpc sata_fsl struct_group() added - add fortify failure condition arguments to warning funcs to assist debugging - add ray_cs compile-time fix - add flexcan compile-time fix - add af_iucv compile-time fix - fix dropped strcpy() compile-time write overflow check - add missing strscpy() compile-time read overflow check - fix more boot stub build instances where fortification must be disabled - add reviewed-bys/acks v1: https://lore.kernel.org/lkml/20210727205855.411487-1-keescook@chromium.org/ Specifically, this series is logically split into several steps: Clean up remaining simple compile-time memcpy() warnings: ipw2x00: Avoid field-overflowing memcpy() net/mlx5e: Avoid field-overflowing memcpy() rpmsg: glink: Replace strncpy() with strscpy_pad() pcmcia: ray_cs: Split memcpy() to avoid bounds check warning Introduce struct_group() and apply it treewide to avoid compile-time memcpy() warnings: stddef: Introduce struct_group() helper macro cxl/core: Replace unions with struct_group() skbuff: Switch structure bounds to struct_group() bnxt_en: Use struct_group_attr() for memcpy() region mwl8k: Use struct_group() for memcpy() region libertas: Use struct_group() for memcpy() region libertas_tf: Use struct_group() for memcpy() region thermal: intel: int340x_thermal: Use struct_group() for memcpy() region iommu/amd: Use struct_group() for memcpy() region cxgb3: Use struct_group() for memcpy() region intersil: Use struct_group() for memcpy() region cxgb4: Use struct_group() for memcpy() region bnx2x: Use struct_group() for memcpy() region drm/amd/pm: Use struct_group() for memcpy() region staging: wlan-ng: Use struct_group() for memcpy() region drm/mga/mga_ioc32: Use struct_group() for memcpy() region net/mlx5e: Use struct_group() for memcpy() region HID: cp2112: Use struct_group() for memcpy() region media: omap3isp: Use struct_group() for memcpy() region sata_fsl: Use struct_group() for memcpy() region Prepare fortify for additional hardening: compiler_types.h: Remove __compiletime_object_size() lib/string: Move helper functions out of string.c fortify: Move remaining fortify helpers into fortify-string.h fortify: Explicitly disable Clang support fortify: Fix dropped strcpy() compile-time write overflow check fortify: Prepare to improve strnlen() and strlen() warnings fortify: Allow strlen() and strnlen() to pass compile-time known lengths Add compile-time and run-time tests: fortify: Add compile-time FORTIFY_SOURCE tests lib: Introduce CONFIG_TEST_MEMCPY Enable new compile-time memcpy() and memmove() bounds checking: fortify: Detect struct member overflows in memcpy() at compile-time fortify: Detect struct member overflows in memmove() at compile-time Clean up remaining simple compile-time memset() warnings: scsi: ibmvscsi: Avoid multi-field memset() overflow by aiming at srp Introduce memset_after() and memset_startat() helpers and apply them (and struct_group()): string.h: Introduce memset_after() for wiping trailing members/padding xfrm: Use memset_after() to clear padding ipv6: Use memset_after() to zero rt6_info netfilter: conntrack: Use memset_startat() to zero struct nf_conn net: 802: Use memset_startat() to clear struct fields net: dccp: Use memset_startat() for TP zeroing net: qede: Use memset_startat() for counters mac80211: Use memset_after() to clear tx status ath11k: Use memset_startat() for clearing queue descriptors iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl intel_th: msu: Use memset_startat() for clearing hw header IB/mthca: Use memset_startat() for clearing mpt_entry btrfs: Use memset_startat() to clear end of struct tracing: Use memset_startat() to zero struct trace_iterator drbd: Use struct_group() to zero algs cm4000_cs: Use struct_group() to zero struct cm4000_dev region KVM: x86: Use struct_group() to zero decode cache dm integrity: Use struct_group() to zero struct journal_sector HID: roccat: Use struct_group() to zero kone_mouse_event RDMA/mlx5: Use struct_group() to zero struct mlx5_ib_mr powerpc/signal32: Use struct_group() to zero spe regs ethtool: stats: Use struct_group() to clear all stats at once can: flexcan: Use struct_group() to zero struct flexcan_regs regions net/af_iucv: Use struct_group() to zero struct iucv_sock region powerpc: Split memset() to avoid multi-field overflow Enable new compile-time memset() bounds checking: fortify: Detect struct member overflows in memset() at compile-time Enable Clang support: fortify: Work around Clang inlining bugs arch/arm/boot/compressed/string.c | 1 + arch/powerpc/include/asm/processor.h | 6 +- arch/powerpc/kernel/signal_32.c | 6 +- arch/s390/lib/string.c | 3 + arch/x86/boot/compressed/misc.c | 3 +- arch/x86/boot/compressed/misc.h | 2 + arch/x86/boot/compressed/pgtable_64.c | 2 + arch/x86/kvm/emulate.c | 3 +- arch/x86/kvm/kvm_emulate.h | 19 +- arch/x86/lib/memcpy_32.c | 1 + arch/x86/lib/string_32.c | 1 + drivers/ata/sata_fsl.c | 10 +- drivers/block/drbd/drbd_main.c | 3 +- drivers/block/drbd/drbd_protocol.h | 6 +- drivers/block/drbd/drbd_receiver.c | 3 +- drivers/char/pcmcia/cm4000_cs.c | 9 +- drivers/cxl/cxl.h | 61 +--- drivers/gpu/drm/amd/include/atomfirmware.h | 9 +- .../drm/amd/pm/inc/smu11_driver_if_arcturus.h | 3 +- .../drm/amd/pm/inc/smu11_driver_if_navi10.h | 3 +- .../amd/pm/inc/smu13_driver_if_aldebaran.h | 3 +- .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 6 +- .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 12 +- .../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 6 +- drivers/gpu/drm/mga/mga_ioc32.c | 27 +- drivers/hid/hid-cp2112.c | 14 +- drivers/hid/hid-roccat-kone.c | 2 +- drivers/hid/hid-roccat-kone.h | 12 +- drivers/hwtracing/intel_th/msu.c | 4 +- drivers/infiniband/hw/cxgb4/cm.c | 5 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +- drivers/infiniband/hw/mthca/mthca_mr.c | 3 +- drivers/iommu/amd/init.c | 9 +- drivers/macintosh/smu.c | 3 +- drivers/md/dm-integrity.c | 9 +- drivers/media/platform/omap3isp/ispstat.c | 5 +- drivers/net/can/flexcan.c | 68 ++-- .../net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 7 +- .../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 14 +- drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 4 +- drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h | 14 +- drivers/net/ethernet/chelsio/cxgb3/sge.c | 9 +- drivers/net/ethernet/chelsio/cxgb4/sge.c | 8 +- drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 2 +- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 10 +- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 7 +- drivers/net/ethernet/mellanox/mlx5/core/en.h | 4 +- .../net/ethernet/mellanox/mlx5/core/en/xdp.c | 4 +- .../net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +- drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +- drivers/net/wireguard/queueing.h | 4 +- drivers/net/wireless/ath/ath11k/hal_rx.c | 13 +- drivers/net/wireless/ath/carl9170/tx.c | 11 +- .../net/wireless/intel/ipw2x00/libipw_rx.c | 56 +--- .../net/wireless/intersil/hostap/hostap_hw.c | 5 +- .../wireless/intersil/hostap/hostap_wlan.h | 14 +- drivers/net/wireless/intersil/p54/txrx.c | 6 +- drivers/net/wireless/marvell/libertas/host.h | 10 +- drivers/net/wireless/marvell/libertas/tx.c | 5 +- .../marvell/libertas_tf/libertas_tf.h | 10 +- .../net/wireless/marvell/libertas_tf/main.c | 3 +- drivers/net/wireless/marvell/mwl8k.c | 10 +- drivers/net/wireless/ray_cs.c | 4 +- drivers/rpmsg/qcom_glink_native.c | 2 +- drivers/scsi/ibmvscsi/ibmvscsi.c | 3 +- drivers/staging/wlan-ng/hfa384x.h | 16 +- drivers/staging/wlan-ng/hfa384x_usb.c | 4 +- .../intel/int340x_thermal/acpi_thermal_rel.c | 5 +- .../intel/int340x_thermal/acpi_thermal_rel.h | 48 +-- fs/btrfs/root-tree.c | 6 +- include/linux/compiler-gcc.h | 2 - include/linux/compiler_types.h | 4 - include/linux/fortify-string.h | 308 +++++++++++++----- include/linux/if_vlan.h | 6 +- include/linux/skbuff.h | 9 +- include/linux/stddef.h | 47 +++ include/linux/string.h | 43 ++- include/linux/thread_info.h | 2 +- include/net/iucv/af_iucv.h | 10 +- include/net/mac80211.h | 7 +- include/uapi/drm/mga_drm.h | 22 +- include/uapi/linux/omap3isp.h | 21 +- include/uapi/linux/stddef.h | 21 ++ kernel/trace/trace.c | 4 +- lib/.gitignore | 2 + lib/Kconfig.debug | 7 + lib/Makefile | 35 ++ lib/string.c | 210 +----------- lib/string_helpers.c | 201 ++++++++++++ lib/test_fortify/read_overflow-memchr.c | 5 + lib/test_fortify/read_overflow-memchr_inv.c | 5 + lib/test_fortify/read_overflow-memcmp.c | 5 + lib/test_fortify/read_overflow-memscan.c | 5 + lib/test_fortify/read_overflow2-memcmp.c | 5 + lib/test_fortify/read_overflow2-memcpy.c | 5 + lib/test_fortify/read_overflow2-memmove.c | 5 + .../read_overflow2_field-memcpy.c | 5 + .../read_overflow2_field-memmove.c | 5 + lib/test_fortify/test_fortify.h | 35 ++ lib/test_fortify/write_overflow-memcpy.c | 5 + lib/test_fortify/write_overflow-memmove.c | 5 + lib/test_fortify/write_overflow-memset.c | 5 + lib/test_fortify/write_overflow-strcpy-lit.c | 5 + lib/test_fortify/write_overflow-strcpy.c | 5 + lib/test_fortify/write_overflow-strlcpy-src.c | 5 + lib/test_fortify/write_overflow-strlcpy.c | 5 + lib/test_fortify/write_overflow-strncpy-src.c | 5 + lib/test_fortify/write_overflow-strncpy.c | 5 + lib/test_fortify/write_overflow-strscpy.c | 5 + .../write_overflow_field-memcpy.c | 5 + .../write_overflow_field-memmove.c | 5 + .../write_overflow_field-memset.c | 5 + lib/test_memcpy.c | 288 ++++++++++++++++ net/802/hippi.c | 2 +- net/core/skbuff.c | 14 +- net/dccp/trace.h | 4 +- net/ethtool/stats.c | 15 +- net/ipv6/route.c | 4 +- net/iucv/af_iucv.c | 2 +- net/netfilter/nf_conntrack_core.c | 4 +- net/xfrm/xfrm_policy.c | 4 +- net/xfrm/xfrm_user.c | 2 +- scripts/test_fortify.sh | 59 ++++ security/Kconfig | 3 + 124 files changed, 1489 insertions(+), 686 deletions(-) create mode 100644 lib/test_fortify/read_overflow-memchr.c create mode 100644 lib/test_fortify/read_overflow-memchr_inv.c create mode 100644 lib/test_fortify/read_overflow-memcmp.c create mode 100644 lib/test_fortify/read_overflow-memscan.c create mode 100644 lib/test_fortify/read_overflow2-memcmp.c create mode 100644 lib/test_fortify/read_overflow2-memcpy.c create mode 100644 lib/test_fortify/read_overflow2-memmove.c create mode 100644 lib/test_fortify/read_overflow2_field-memcpy.c create mode 100644 lib/test_fortify/read_overflow2_field-memmove.c create mode 100644 lib/test_fortify/test_fortify.h create mode 100644 lib/test_fortify/write_overflow-memcpy.c create mode 100644 lib/test_fortify/write_overflow-memmove.c create mode 100644 lib/test_fortify/write_overflow-memset.c create mode 100644 lib/test_fortify/write_overflow-strcpy-lit.c create mode 100644 lib/test_fortify/write_overflow-strcpy.c create mode 100644 lib/test_fortify/write_overflow-strlcpy-src.c create mode 100644 lib/test_fortify/write_overflow-strlcpy.c create mode 100644 lib/test_fortify/write_overflow-strncpy-src.c create mode 100644 lib/test_fortify/write_overflow-strncpy.c create mode 100644 lib/test_fortify/write_overflow-strscpy.c create mode 100644 lib/test_fortify/write_overflow_field-memcpy.c create mode 100644 lib/test_fortify/write_overflow_field-memmove.c create mode 100644 lib/test_fortify/write_overflow_field-memset.c create mode 100644 lib/test_memcpy.c create mode 100644 scripts/test_fortify.sh -- 2.30.2

23 117

[Bug 203439] New: amdgpu: [REG 4.20 -> 5.0] Brightness minimum level is too high
by bugzilla-daemon＠bugzilla.kernel.org 24 Nov '21

24 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=203439 Bug ID: 203439 Summary: amdgpu: [REG 4.20 -> 5.0] Brightness minimum level is too high Product: Drivers Version: 2.5 Kernel Version: 5.0 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: spaz16(a)wp.pl Regression: No I have Huawei Matebook D 14 with AMD Ryzen 2500U. Since kernel 5.0.x the minimum brightness level is too high. It is not possible to dim the display as much as on previous kernel version. Kernel 4.20 also allows to disable the backlight on level 0. Value of "0" in "/sys/class/backlight/amdgpu_bl0/brightness" currently doesn't disable backlight as in previous version. Value of "1" means the screen is dim, but not as much as in kernel 4.20. Sometimes the screen is still too bright even on level 0 in kernel 5.0. Since commit 206bbafe00dcacccf40e6f09e624329ec124201b I can see the define: > #define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12 Maybe it should be defined to "0" to restore the old behavior? (I haven't tested yet) -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 213391] New: AMDGPU retries page fault with some specific processes amdgpu: [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered
by bugzilla-daemon＠bugzilla.kernel.org 19 Nov '21

19 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=213391 Bug ID: 213391 Summary: AMDGPU retries page fault with some specific processes amdgpu: [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered Product: Drivers Version: 2.5 Kernel Version: Linux 5.12.9-arch-1-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: samy(a)lahfa.xyz Regression: No Hi, I just updated recently from mainstream Kernel 5.11.16 to 5.12.9 and I've ran into this issue, I've also updated the Mesa driver from mesa-git (21.1.0_devel.137307.f8e5f945b8f-1) to mesa-git (21.2.0_devel.140633.c04f20e7e01-1). Current kernel parameters : /vmlinuz-linux zfs=zroot/ROOT/default rw loglevel=3 quiet radeon.si_support=0 amdgpu.si_support=1 radeon.cik_support=0 amdgpu.cik_support=1 My computer is a Thinkpad T495 laptop (AMD Ryzen 7 3700 Pro with an iGPU RX VEGA 10, 16GB DDR4 3200Mhz) the very important bit of information is that the BIOS reserves up to 2GB of DDR4 RAM for the iGPU VRAM, I currently have setup 1GB (1024MB) of RAM in my BIOS for the iGPU, I'm thinking the page fault retries could be linked to this in someways. I think this has a higher chance of happening when my RAM memory is under heavy load and the system is swapping quite a lot too. (I have 12.3GB of Swap on a NVMe PCIe 3.0) At present, I cannot reproduce this issue consistently yet, however it has been happening with web browsers Qutebrowser (more with Qutebrowser) and also happened only once with Chromium (made the X11 server crash and the computer completely froze, kernel was still responsive to SysReq keys hence I could get out of that tricky situation safely). I'll be uploading both logs of the crashes I have encountered along with an lspci and other logs files that could be useful. Kind regards, Lahfa Samy -- 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 40

[PATCH] drm/nouveau/core: fix the uninitialized use in nvkm_ioctl_map()
by Yizhuo Zhai 16 Nov '21

16 Nov '21

In function nvkm_ioctl_map(), the variable "type" could be uninitialized if "nvkm_object_map()" returns error code, however, it does not check the return value and directly use the "type" in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003(a)ucr.edu> --- drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c index d777df5a64e6..7f2e8482f167 100644 --- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c +++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c @@ -266,6 +266,8 @@ nvkm_ioctl_map(struct nvkm_client *client, ret = nvkm_object_map(object, data, size, &type, &args->v0.handle, &args->v0.length); + if (ret) + return ret; if (type == NVKM_OBJECT_MAP_IO) args->v0.type = NVIF_IOCTL_MAP_V0_IO; else -- 2.17.1

2 3

[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood
by Andy Shevchenko 15 Nov '21

15 Nov '21

We have already few similar implementation and a lot of code that can benefit of the yesno() helper. Consolidate yesno() helpers under string.h hood. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +----- drivers/gpu/drm/i915/i915_utils.h | 6 +----- drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 12 +----------- include/linux/string.h | 5 +++++ 4 files changed, 8 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index 360952129b6d..7fde4f90e513 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -23,6 +23,7 @@ * */ +#include <linux/string.h> #include <linux/uaccess.h> #include <drm/drm_debugfs.h> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry { uint32_t param1; }; -static inline const char *yesno(bool v) -{ - return v ? "yes" : "no"; -} - /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array * * Function takes in attributes passed to debugfs write entry diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h index abd4dcd9f79c..e6da5a951132 100644 --- a/drivers/gpu/drm/i915/i915_utils.h +++ b/drivers/gpu/drm/i915/i915_utils.h @@ -27,6 +27,7 @@ #include <linux/list.h> #include <linux/overflow.h> +#include <linux/string.h> #include <linux/sched.h> #include <linux/types.h> #include <linux/workqueue.h> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms) #define MBps(x) KBps(1000 * (x)) #define GBps(x) ((u64)1000 * MBps((x))) -static inline const char *yesno(bool v) -{ - return v ? "yes" : "no"; -} - static inline const char *onoff(bool v) { return v ? "on" : "off"; diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c index 7d49fd4edc9e..c857d73abbd7 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c @@ -34,6 +34,7 @@ #include <linux/seq_file.h> #include <linux/debugfs.h> +#include <linux/string.h> #include <linux/string_helpers.h> #include <linux/sort.h> #include <linux/ctype.h> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = { /* RSS Configuration. */ -/* Small utility function to return the strings "yes" or "no" if the supplied - * argument is non-zero. - */ -static const char *yesno(int x) -{ - static const char *yes = "yes"; - static const char *no = "no"; - - return x ? yes : no; -} - static int rss_config_show(struct seq_file *seq, void *v) { struct adapter *adapter = seq->private; diff --git a/include/linux/string.h b/include/linux/string.h index 9521d8cab18e..fd946a5e18c8 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix return strncmp(str, prefix, len) == 0 ? len : 0; } +static inline const char *yesno(bool yes) +{ + return yes ? "yes" : "no"; +} + #endif /* _LINUX_STRING_H_ */ -- 2.30.0

6 12

[Bug 213823] New: Broken power management for amdgpu
by bugzilla-daemon＠bugzilla.kernel.org 14 Nov '21

14 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=213823 Bug ID: 213823 Summary: Broken power management for amdgpu Product: Drivers Version: 2.5 Kernel Version: 5.13.4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: bruno.n.pagani(a)gmail.com Regression: No Created attachment 298003 --> https://bugzilla.kernel.org/attachment.cgi?id=298003&action=edit amdgpu dmesg output on 5.12 After upgrading to kernel 5.13.4 (from 5.12.15, on Arch Linux), I’ve realized my AMD dGPU was not powering off anymore resulting in increased power consumption, heat and noise (because of the fan trying to dissipate the heat). I’ve compared kernel dmesg on both kernels, and I’ve found related differences: @@ -1,4 +1,6 @@ [drm] amdgpu kernel modesetting enabled. +amdgpu: CRAT table not found +amdgpu: Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node fb0: switching to amdgpudrmfb from EFI VGA amdgpu 0000:01:00.0: enabling device (0006 -> 0007) @@ -14,7 +16,10 @@ amdgpu 0000:01:00.0: amdgpu: GART: 256M 0x000000FF00000000 - 0x000000FF0FFFFFFF [drm] amdgpu: 4096M of VRAM memory ready [drm] amdgpu: 4096M of GTT memory ready. amdgpu: hwmgr_sw_init smu backed is vegam_smu +kfd kfd: amdgpu: Allocated 3969056 bytes on gart +amdgpu: Virtual CRAT table created for GPU amdgpu: Topology: Add dGPU node [0x694f:0x1002] +kfd kfd: amdgpu: added device 1002:694f amdgpu 0000:01:00.0: amdgpu: SE 4, SH per SE 1, CU per SH 6, active_cu_number 20 -amdgpu 0000:01:00.0: amdgpu: Using ATPX for runtime pm -[drm] Initialized amdgpu 3.40.0 20150101 for 0000:01:00.0 on minor 1 +amdgpu 0000:01:00.0: amdgpu: Using BOCO for runtime pm +[drm] Initialized amdgpu 3.41.0 20150101 for 0000:01:00.0 on minor 1 I’ve attached both excerpt matching the diff above. FWIW, this is a Dell Precision 5530 2-in-1 with a Kaby Lake-G CPU, which has an Intel HD 630 iGPU as well as an AMD Polaris 22 MGL XL [Radeon Pro WX Vega M GL] dGPU. Please tell me if there is anything else that I can provide in order to fix this. -- 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 7

[PATCH] drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()
by Thomas Zimmermann 12 Nov '21

12 Nov '21

The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this with a call to dma_free_noncoherent(). Writecombining storage is still released with dma_free_wc(). Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent memory") Cc: Paul Cercueil <paul(a)crapouillou.net> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index d53388199f34..9d05674550a4 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -210,8 +210,13 @@ void drm_gem_cma_free_object(struct drm_gem_object *gem_obj) dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map); drm_prime_gem_destroy(gem_obj, cma_obj->sgt); } else if (cma_obj->vaddr) { - dma_free_wc(gem_obj->dev->dev, cma_obj->base.size, - cma_obj->vaddr, cma_obj->paddr); + if (cma_obj->map_noncoherent) + dma_free_noncoherent(gem_obj->dev->dev, cma_obj->base.size, + cma_obj->vaddr, cma_obj->paddr, + DMA_TO_DEVICE); + else + dma_free_wc(gem_obj->dev->dev, cma_obj->base.size, + cma_obj->vaddr, cma_obj->paddr); } drm_gem_object_release(gem_obj); -- 2.32.0

2 3

[PATCH 1/2] drm/sched: fix the bug of time out calculation(v3)
by Monk Liu 11 Nov '21

11 Nov '21

issue: in cleanup_job the cancle_delayed_work will cancel a TO timer even the its corresponding job is still running. fix: do not cancel the timer in cleanup_job, instead do the cancelling only when the heading job is signaled, and if there is a "next" job we start_timeout again. v2: further cleanup the logic, and do the TDR timer cancelling if the signaled job is the last one in its scheduler. v3: change the issue description remove the cancel_delayed_work in the begining of the cleanup_job recover the implement of drm_sched_job_begin. TODO: 1)introduce pause/resume scheduler in job_timeout to serial the handling of scheduler and job_timeout. 2)drop the bad job's del and insert in scheduler due to above serialization (no race issue anymore with the serialization) tested-by: jingwen <jingwen.chen@@amd.com> Signed-off-by: Monk Liu <Monk.Liu(a)amd.com> --- drivers/gpu/drm/scheduler/sched_main.c | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index a2a9536..ecf8140 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -676,13 +676,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) { struct drm_sched_job *job, *next; - /* - * Don't destroy jobs while the timeout worker is running OR thread - * is being parked and hence assumed to not touch pending_list - */ - if ((sched->timeout != MAX_SCHEDULE_TIMEOUT && - !cancel_delayed_work(&sched->work_tdr)) || - kthread_should_park()) + if (kthread_should_park()) return NULL; spin_lock(&sched->job_list_lock); @@ -693,17 +687,21 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) if (job && dma_fence_is_signaled(&job->s_fence->finished)) { /* remove job from pending_list */ list_del_init(&job->list); + + /* cancel this job's TO timer */ + cancel_delayed_work(&sched->work_tdr); /* make the scheduled timestamp more accurate */ next = list_first_entry_or_null(&sched->pending_list, typeof(*next), list); - if (next) + + if (next) { next->s_fence->scheduled.timestamp = job->s_fence->finished.timestamp; - + /* start TO timer for next job */ + drm_sched_start_timeout(sched); + } } else { job = NULL; - /* queue timeout for next job */ - drm_sched_start_timeout(sched); } spin_unlock(&sched->job_list_lock); @@ -791,11 +789,8 @@ static int drm_sched_main(void *param) (entity = drm_sched_select_entity(sched))) || kthread_should_stop()); - if (cleanup_job) { + if (cleanup_job) sched->ops->free_job(cleanup_job); - /* queue timeout for next job */ - drm_sched_start_timeout(sched); - } if (!entity) continue; -- 2.7.4

8 26

[PATCH v2 00/22] drm/msm/dpu: switch dpu_plane to be virtual
by Dmitry Baryshkov 10 Nov '21

10 Nov '21

As discussed on IRC, change dpu_plane implementation to be virtual: register unified planes and select backing SSPP block at runtime. Use msm.dpu_use_virtual_planes=1 to enable usage of virtual planes rather than statically allocated SSPPs at the plane registration. Patches 1-9 move state variables from struct dpu_plane onto the stack allocation. State should not be a part of struct dpu_plane anyway. Patches 10-18 make additional changes to plane code, reworking check, debugfs, dropping old multirec support, which results in patch 19 adding support for virtual planes per se. Patches 20-22 demonstrate my main goal behind reworking dpu_plane support. They change dpu_plane to automatically use one of SSPP block features - multirec, an ability to display two unscaled RGB rectangles using single SSPP block. This allows us to double the amount of created planes. If the user tries to enable more planes than actually supported by the underlying SSPP blocks, atomic_check code would return an error. As you can see, this patchset is not atomic, so different patches can go separately. Changes since v1: - Add multirec implementation - Added msm.dpu_use_virtual_planes kernel parameter instead of using compile time switch - Changed code to always reallocate SSPPs in the CRTC atomic check to let the kernel pick up the best multirec config. This can be optimized later. - Rework RM SSPP API to always receive plane id - Removed scaler_cfg, pixel_ext and cdp_cfg from struct dpu_plane_state - Made _dpu_scaler_setup() call sspp's setup_scaler and setup_pe - Removed dpu_csc_cfg from dpu_plane The following changes since commit e88bbc91849b2bf57683119c339e52916d34433f: Revert "drm/msm/mdp5: provide dynamic bandwidth management" (2021-06-23 14:06:20 -0700) are available in the Git repository at: https://git.linaro.org/people/dmitry.baryshkov/kernel.git dpu-multirec-2 for you to fetch changes up to 19f6afd40097d4c826e56b8f4a8cbd807f7b61f6: drm/msm/dpu: add multirect support (2021-07-05 04:04:50 +0300) ---------------------------------------------------------------- Dmitry Baryshkov (22): drm/msm/dpu: move LUT levels out of QOS config drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane drm/msm/dpu: drop pipe_name from struct dpu_plane drm/msm/dpu: remove stage_cfg from struct dpu_crtc drm/msm/dpu: rip out master planes support drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane drm/msm/dpu: drop scaler config from plane state drm/msm/dpu: drop dpu_csc_cfg from dpu_plane drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg from dpu_plane drm/msm/dpu: don't cache pipe->cap->features in dpu_plane drm/msm/dpu: don't cache pipe->cap->sblk in dpu_plane drm/msm/dpu: rip out debugfs support from dpu_plane drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check drm/msm/dpu: add list of supported formats to the DPU caps drm/msm/dpu: simplify DPU_SSPP features checks drm/msm/dpu: do not limit the zpos property drm/msm/dpu: add support for SSPP allocation to RM drm/msm/dpu: move pipe_hw to dpu_plane_state drm/msm/dpu: add support for virtualized planes drm/msm/dpu: fix smart dma support drm/msm/dpu: fix CDP setup to account for multirect index drm/msm/dpu: add multirect support drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 261 +++----- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 41 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 52 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 234 ++++--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 70 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 851 +++++++++++-------------- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 75 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 81 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 + 14 files changed, 793 insertions(+), 924 deletions(-)

2 34

[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

← Newer
1
...
4
5
6
7
8
9
10
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021