Skip to content

[PW_SID:928000] Enable Zicbom in usermode#5

Closed
linux-riscv-bot wants to merge 4 commits intoworkflow__riscv__fixesfrom
pw928000
Closed

[PW_SID:928000] Enable Zicbom in usermode#5
linux-riscv-bot wants to merge 4 commits intoworkflow__riscv__fixesfrom
pw928000

Conversation

@linux-riscv-bot
Copy link

@linux-riscv-bot linux-riscv-bot commented Jan 29, 2025

PR for series 928000 applied to workflow__riscv__fixes

Name: Enable Zicbom in usermode
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=928000
Version: 6

Linux RISC-V bot and others added 4 commits January 29, 2025 12:19
Adding CI files
a7bbdd0
@cuiyunhui
RISC-V: Enable cbo.clean/flush in usermode
f80bdbe 
Enabling cbo.clean and cbo.flush in user mode makes it more
convenient to manage the cache state and achieve better performance.

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
@cuiyunhui
RISC-V: hwprobe: Expose Zicbom extension and its block size
1fda04b 
Expose Zicbom through hwprobe and also provide a key to extract its
respective block size.

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
@cuiyunhui
RISC-V: selftests: Add TEST_ZICBOM into CBO tests
a0b6dba 
Add test for Zicbom and its block size into CBO tests, when
Zicbom is present, test that cbo.clean/flush may be issued and works.
As the software can't verify the clean/flush functions, we just judged
that cbo.clean/flush isn't executed illegally.

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 121.30 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1091.79 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 1357.74 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 22.00 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 23.05 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 0.68 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 42.57 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.23 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
kdoc
Desc: Detects for kdoc errors
Duration: 0.82 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
module-param
Desc: Detect module_param changes
Duration: 0.26 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.24 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 1: "[v6,1/3] RISC-V: Enable cbo.clean/flush in usermode"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.29 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 119.69 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1137.61 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 1404.86 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 20.29 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 22.74 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 2.12 seconds
Result: WARNING
Output:

CHECK: Prefer using the BIT_ULL macro
#62: FILE: arch/riscv/include/uapi/asm/hwprobe.h:76:
+#define		RISCV_HWPROBE_EXT_ZICBOM	(1ULL << 50)

total: 0 errors, 0 warnings, 1 checks, 63 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Commit 1fda04b60a8c ("RISC-V: hwprobe: Expose Zicbom extension and its block size") has style problems, please review.

NOTE: Ignored message types: ALLOC_SIZEOF_STRUCT CAMELCASE COMMIT_LOG_LONG_LINE GIT_COMMIT_ID MACRO_ARG_REUSE NO_AUTHOR_SIGN_OFF

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 1 checks, 63 lines checked
CHECK: Prefer using the BIT_ULL macro

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 41.77 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.22 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
kdoc
Desc: Detects for kdoc errors
Duration: 0.79 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
module-param
Desc: Detect module_param changes
Duration: 0.25 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.47 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 2: "[v6,2/3] RISC-V: hwprobe: Expose Zicbom extension and its block size"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.58 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 118.86 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1055.44 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 1307.08 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 20.72 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 22.66 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 0.74 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 42.71 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.22 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
kdoc
Desc: Detects for kdoc errors
Duration: 0.83 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
module-param
Desc: Detect module_param changes
Duration: 0.24 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.22 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

linux-riscv-bot commented Jan 29, 2025

Patch 3: "[v6,3/3] RISC-V: selftests: Add TEST_ZICBOM into CBO tests"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.31 seconds
Result: PASS

@linux-riscv-bot linux-riscv-bot force-pushed the workflow__riscv__fixes branch 4 times, most recently from 269dca8 to e7cc131 Compare January 30, 2025 13:34
@linux-riscv-bot linux-riscv-bot deleted the pw928000 branch February 1, 2025 00:59
AlexGhiti pushed a commit that referenced this pull request May 13, 2025
@ant2a @marckleinebudde
can: m_can: m_can_class_allocate_dev(): initialize spin lock on devic…
dcaeeb8 
…e probe

The spin lock tx_handling_spinlock in struct m_can_classdev is not
being initialized. This leads the following spinlock bad magic
complaint from the kernel, eg. when trying to send CAN frames with
cansend from can-utils:

| BUG: spinlock bad magic on CPU#0, cansend/95
|  lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
| CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE
| Hardware name: MachineWare SIM-V (DT)
| Call Trace:
| [<ffffffff800133e0>] dump_backtrace+0x1c/0x24
| [<ffffffff800022f2>] show_stack+0x28/0x34
| [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68
| [<ffffffff8000de70>] dump_stack+0x14/0x1c
| [<ffffffff80003134>] spin_dump+0x62/0x6e
| [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142
| [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c
| [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a
| [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee
| [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292
| [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8
| [<ffffffff8073b8fa>] can_send+0xc6/0x242
| [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c
| [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee
| [<ffffffff801d06ea>] vfs_write+0x184/0x3a6
| [<ffffffff801d0a88>] ksys_write+0xa0/0xc0
| [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c
| [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212
| [<ffffffff807a830a>] handle_exception+0x146/0x152

Initializing the spin lock in m_can_class_allocate_dev solves that
problem.

Fixes: 1fa80e2 ("can: m_can: Introduce a tx_fifo_in_flight counter")
Signed-off-by: Antonios Salios <antonios@mwa.re>
Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/20250425111744.37604-2-antonios@mwa.re
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
AlexGhiti pushed a commit that referenced this pull request Jun 2, 2025
@rostedt
ring-buffer: Move cpus_read_lock() outside of buffer->mutex
c98cc97 
Running a modified trace-cmd record --nosplice where it does a mmap of the
ring buffer when '--nosplice' is set, caused the following lockdep splat:

 ======================================================
 WARNING: possible circular locking dependency detected
 6.15.0-rc7-test-00002-gfb7d03d8a82f #551 Not tainted
 ------------------------------------------------------
 trace-cmd/1113 is trying to acquire lock:
 ffff888100062888 (&buffer->mutex){+.+.}-{4:4}, at: ring_buffer_map+0x11c/0xe70

 but task is already holding lock:
 ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #5 (&cpu_buffer->mapping_lock){+.+.}-{4:4}:
        __mutex_lock+0x192/0x18c0
        ring_buffer_map+0xcf/0xe70
        tracing_buffers_mmap+0x1c4/0x3b0
        __mmap_region+0xd8d/0x1f70
        do_mmap+0x9d7/0x1010
        vm_mmap_pgoff+0x20b/0x390
        ksys_mmap_pgoff+0x2e9/0x440
        do_syscall_64+0x79/0x1c0
        entry_SYSCALL_64_after_hwframe+0x76/0x7e

 -> #4 (&mm->mmap_lock){++++}-{4:4}:
        __might_fault+0xa5/0x110
        _copy_to_user+0x22/0x80
        _perf_ioctl+0x61b/0x1b70
        perf_ioctl+0x62/0x90
        __x64_sys_ioctl+0x134/0x190
        do_syscall_64+0x79/0x1c0
        entry_SYSCALL_64_after_hwframe+0x76/0x7e

 -> #3 (&cpuctx_mutex){+.+.}-{4:4}:
        __mutex_lock+0x192/0x18c0
        perf_event_init_cpu+0x325/0x7c0
        perf_event_init+0x52a/0x5b0
        start_kernel+0x263/0x3e0
        x86_64_start_reservations+0x24/0x30
        x86_64_start_kernel+0x95/0xa0
        common_startup_64+0x13e/0x141

 -> #2 (pmus_lock){+.+.}-{4:4}:
        __mutex_lock+0x192/0x18c0
        perf_event_init_cpu+0xb7/0x7c0
        cpuhp_invoke_callback+0x2c0/0x1030
        __cpuhp_invoke_callback_range+0xbf/0x1f0
        _cpu_up+0x2e7/0x690
        cpu_up+0x117/0x170
        cpuhp_bringup_mask+0xd5/0x120
        bringup_nonboot_cpus+0x13d/0x170
        smp_init+0x2b/0xf0
        kernel_init_freeable+0x441/0x6d0
        kernel_init+0x1e/0x160
        ret_from_fork+0x34/0x70
        ret_from_fork_asm+0x1a/0x30

 -> #1 (cpu_hotplug_lock){++++}-{0:0}:
        cpus_read_lock+0x2a/0xd0
        ring_buffer_resize+0x610/0x14e0
        __tracing_resize_ring_buffer.part.0+0x42/0x120
        tracing_set_tracer+0x7bd/0xa80
        tracing_set_trace_write+0x132/0x1e0
        vfs_write+0x21c/0xe80
        ksys_write+0xf9/0x1c0
        do_syscall_64+0x79/0x1c0
        entry_SYSCALL_64_after_hwframe+0x76/0x7e

 -> #0 (&buffer->mutex){+.+.}-{4:4}:
        __lock_acquire+0x1405/0x2210
        lock_acquire+0x174/0x310
        __mutex_lock+0x192/0x18c0
        ring_buffer_map+0x11c/0xe70
        tracing_buffers_mmap+0x1c4/0x3b0
        __mmap_region+0xd8d/0x1f70
        do_mmap+0x9d7/0x1010
        vm_mmap_pgoff+0x20b/0x390
        ksys_mmap_pgoff+0x2e9/0x440
        do_syscall_64+0x79/0x1c0
        entry_SYSCALL_64_after_hwframe+0x76/0x7e

 other info that might help us debug this:

 Chain exists of:
   &buffer->mutex --> &mm->mmap_lock --> &cpu_buffer->mapping_lock

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&cpu_buffer->mapping_lock);
                                lock(&mm->mmap_lock);
                                lock(&cpu_buffer->mapping_lock);
   lock(&buffer->mutex);

  *** DEADLOCK ***

 2 locks held by trace-cmd/1113:
  #0: ffff888106b847e0 (&mm->mmap_lock){++++}-{4:4}, at: vm_mmap_pgoff+0x192/0x390
  #1: ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70

 stack backtrace:
 CPU: 5 UID: 0 PID: 1113 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00002-gfb7d03d8a82f #551 PREEMPT
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 Call Trace:
  <TASK>
  dump_stack_lvl+0x6e/0xa0
  print_circular_bug.cold+0x178/0x1be
  check_noncircular+0x146/0x160
  __lock_acquire+0x1405/0x2210
  lock_acquire+0x174/0x310
  ? ring_buffer_map+0x11c/0xe70
  ? ring_buffer_map+0x11c/0xe70
  ? __mutex_lock+0x169/0x18c0
  __mutex_lock+0x192/0x18c0
  ? ring_buffer_map+0x11c/0xe70
  ? ring_buffer_map+0x11c/0xe70
  ? function_trace_call+0x296/0x370
  ? __pfx___mutex_lock+0x10/0x10
  ? __pfx_function_trace_call+0x10/0x10
  ? __pfx___mutex_lock+0x10/0x10
  ? _raw_spin_unlock+0x2d/0x50
  ? ring_buffer_map+0x11c/0xe70
  ? ring_buffer_map+0x11c/0xe70
  ? __mutex_lock+0x5/0x18c0
  ring_buffer_map+0x11c/0xe70
  ? do_raw_spin_lock+0x12d/0x270
  ? find_held_lock+0x2b/0x80
  ? _raw_spin_unlock+0x2d/0x50
  ? rcu_is_watching+0x15/0xb0
  ? _raw_spin_unlock+0x2d/0x50
  ? trace_preempt_on+0xd0/0x110
  tracing_buffers_mmap+0x1c4/0x3b0
  __mmap_region+0xd8d/0x1f70
  ? ring_buffer_lock_reserve+0x99/0xff0
  ? __pfx___mmap_region+0x10/0x10
  ? ring_buffer_lock_reserve+0x99/0xff0
  ? __pfx_ring_buffer_lock_reserve+0x10/0x10
  ? __pfx_ring_buffer_lock_reserve+0x10/0x10
  ? bpf_lsm_mmap_addr+0x4/0x10
  ? security_mmap_addr+0x46/0xd0
  ? lock_is_held_type+0xd9/0x130
  do_mmap+0x9d7/0x1010
  ? 0xffffffffc0370095
  ? __pfx_do_mmap+0x10/0x10
  vm_mmap_pgoff+0x20b/0x390
  ? __pfx_vm_mmap_pgoff+0x10/0x10
  ? 0xffffffffc0370095
  ksys_mmap_pgoff+0x2e9/0x440
  do_syscall_64+0x79/0x1c0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 RIP: 0033:0x7fb0963a7de2
 Code: 00 00 00 0f 1f 44 00 00 41 f7 c1 ff 0f 00 00 75 27 55 89 cd 53 48 89 fb 48 85 ff 74 3b 41 89 ea 48 89 df b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 5b 5d c3 0f 1f 00 48 8b 05 e1 9f 0d 00 64
 RSP: 002b:00007ffdcc8fb878 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb0963a7de2
 RDX: 0000000000000001 RSI: 0000000000001000 RDI: 0000000000000000
 RBP: 0000000000000001 R08: 0000000000000006 R09: 0000000000000000
 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
 R13: 00007ffdcc8fbe68 R14: 00007fb096628000 R15: 00005633e01a5c90
  </TASK>

The issue is that cpus_read_lock() is taken within buffer->mutex. The
memory mapped pages are taken with the mmap_lock held. The buffer->mutex
is taken within the cpu_buffer->mapping_lock. There's quite a chain with
all these locks, where the deadlock can be fixed by moving the
cpus_read_lock() outside the taking of the buffer->mutex.

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Link: https://lore.kernel.org/20250527105820.0f45d045@gandalf.local.home
Fixes: 117c392 ("ring-buffer: Introducing ring-buffer mapping functions")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@linux-riscv-bot @cuiyunhui