Skip to content

Conversation

@linux-riscv-bot
Copy link

PR for series 932338 applied to workflow__riscv__fixes

Name: riscv: cpufeature: use bitmap_equal() instead of memcmp()
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=932338
Version: 1

Linux RISC-V bot and others added 2 commits February 6, 2025 06:50
Comparison of bitmaps should be done using bitmap_equal(), not memcmp(),
use the former one to compare isa bitmaps.

Signed-off-by: Clément Léger <cleger@rivosinc.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 122.98 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1116.49 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 1369.69 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 21.09 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 23.30 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 3.69 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 45.24 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.22 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
kdoc
Desc: Detects for kdoc errors
Duration: 1.22 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
module-param
Desc: Detect module_param changes
Duration: 0.25 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.21 seconds
Result: PASS

@linux-riscv-bot
Copy link
Author

Patch 1: "riscv: cpufeature: use bitmap_equal() instead of memcmp()"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.28 seconds
Result: PASS

@linux-riscv-bot linux-riscv-bot force-pushed the workflow__riscv__fixes branch 2 times, most recently from c719a38 to 106fc72 Compare February 13, 2025 18:49
@linux-riscv-bot linux-riscv-bot deleted the pw932338 branch February 13, 2025 18:50
AlexGhiti pushed a commit that referenced this pull request Mar 3, 2025
Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts
locally") moved the call to enable_drhd_fault_handling() to a code
path that does not hold any lock while traversing the drhd list. Fix
it by ensuring the dmar_global_lock lock is held when traversing the
drhd list.

Without this fix, the following warning is triggered:
 =============================
 WARNING: suspicious RCU usage
 6.14.0-rc3 #55 Not tainted
 -----------------------------
 drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!
               other info that might help us debug this:
               rcu_scheduler_active = 1, debug_locks = 1
 2 locks held by cpuhp/1/23:
 #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 stack backtrace:
 CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55
 Call Trace:
  <TASK>
  dump_stack_lvl+0xb7/0xd0
  lockdep_rcu_suspicious+0x159/0x1f0
  ? __pfx_enable_drhd_fault_handling+0x10/0x10
  enable_drhd_fault_handling+0x151/0x180
  cpuhp_invoke_callback+0x1df/0x990
  cpuhp_thread_fun+0x1ea/0x2c0
  smpboot_thread_fn+0x1f5/0x2e0
  ? __pfx_smpboot_thread_fn+0x10/0x10
  kthread+0x12a/0x2d0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x4a/0x60
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  </TASK>

Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat
about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.
This is avoided by not holding dmar_global_lock when calling
iommu_device_register(), which initiates the device probe process.

Fixes: d74169c ("iommu/vt-d: Allocate DMAR fault interrupts locally")
Reported-and-tested-by: Ido Schimmel <idosch@nvidia.com>
Closes: https://lore.kernel.org/linux-iommu/Zx9OwdLIc_VoQ0-a@shredder.mtl.com/
Tested-by: Breno Leitao <leitao@debian.org>
Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/20250218022422.2315082-1-baolu.lu@linux.intel.com
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants