[PATCH 00/62] Bug fixes and refactoring patches related to locking

[PATCH 00/62] Bug fixes and refactoring patches related to locking

[Bart Van Assche]

Hi Peter,

Annotating all source files in the kernel tree with lock context annotations
led to the discovery of a significant number of locking bugs. This patch
series includes fixes for the discovered bugs. Additionally, multiple
refactoring patches have been included that make it easier for the compiler
to verify correctness of locking operations. Please consider this patch series
for the next merge window.

While the previous version of this patch series only covered mutexes, this
patch series covers all synchronization operations currently annotated with
lock context annotations. The previous version is available here:
[PATCH RFC 00/33] Compile-time thread-safety checking, LKML, February 2025
(https://lore.kernel.org/lkml/20250206175114.1974171-1-bvanassche@acm.org/).

Thanks,

Bart.

Bart Van Assche (62):
  kvm: Make pi_enable_wakeup_handler() easier to analyze
  blk-ioc: Prepare for enabling thread-safety analysis
  drbd: Balance RCU calls in drbd_adm_dump_devices()
  dax/bus.c: Fix a locking bug
  dma-buf: Convert dma_buf_import_sync_file() to the early-return style
  dma-buf: Handle all dma_resv_lock() errors
  drm/amdgpu: Unlock a mutex before destroying it
  drm/amdgpu: Fix locking bugs in error paths
  drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path
  drm: Make drm_read() easier to analyze
  drm/pagemap: Unlock cache->lock before freeing it
  drm/gpusvm.c: Fix a locking bug in an error path
  drm/qxl: Fix a buffer leak in an error path
  hwmon: (it87) Check the it87_lock() return value
  Input: synaptics-rmi4 - fix a locking bug in an error path
  md: Make mddev_suspend() easier to analyze
  bnxt_en: Make bnxt_resume() easier to analyze
  bnxt_en: Fix bnxt_dl_reload_up()
  ice: Fix a locking bug in an error path
  octeontx2-pf: Fix locking in an error path
  qed: Make _qed_mcp_cmd_and_union() easier to analyze
  mctp i3c: Fix locking in error paths
  net: phy: mxl-86110: Fix locking in an error path
  net/cw1200: Fix locking in error paths
  wlcore: Fix a locking bug
  misc: nsm: Fix a locking bug in an error path
  pci: Fix locking in pci_do_resource_release_and_resize() error paths
  PNP: isapnp: Check the isapnp_cfg_begin() return value
  fnic: Make fnic_queuecommand() easier to analyze
  megaraid: Protect more code with instance->reset_mutex
  target: Make transport_handle_queue_full() easier to analyze
  usbip: Move a check outside put_busid_priv()
  fbdev/omap2: Make the source code easier to analyze
  btrfs: Fix a bug in try_release_subpage_extent_buffer()
  cachefiles: Fix a locking bug in an error path
  f2fs: Fix handling of radix_tree_preload() failures
  lib: Split codetag_lock_module_list()
  treewide: Modify mutex_lock_interruptible() return value checks
  accel/ivpu: Check the ivpu_bo_lock() return value
  dma-buf: Check the dma_resv_lock() return value
  drm: Check the dma_resv_lock() return value
  drm/amdgpu: Check the dma_resv_lock() return value
  drm/gma500: Check the dma_resv_lock() return value
  drm/i915: Check the dma_resv_lock() return value
  drm/imagination: Check the dma_resv_lock() return value
  drm/lima: Check the dma_resv_lock() return value
  drm/loongson: Check the dma_resv_lock() return value
  drm/msm: Check the dma_resv_lock() return value
  drm/nouveau: Check the dma_resv_lock() return value
  drm/panfrost: Check the dma_resv_lock() return value
  drm/panthor: Check the dma_resv_lock() return value
  drm/radeon: Check the dma_resv_lock() return value
  drm/ttm: Check the dma_resv_lock() return value
  drm/vgem: Check the dma_resv_lock() return value
  drm/virtio: Check the dma_resv_lock() return value
  drm/vmwgfx: Check the dma_resv_lock() return value
  drm/xe: Check the dma_resv_lock() return value
  RDMA/core: Check the dma_resv_lock() return value
  RDMA/mlx5: Check the dma_resv_lock() return value
  iommufd: Check the dma_resv_lock() return value
  vfio/pci: Check the dma_resv_lock() return value
  dma-resv: Make checking the dma_resv_lock() return value mandatory

 arch/x86/kvm/vmx/posted_intr.c                |  7 +-
 block/blk-ioc.c                               |  2 +-
 drivers/accel/ivpu/ivpu_gem.c                 | 41 ++++++++----
 drivers/block/drbd/drbd_nl.c                  |  8 ++-
 drivers/dax/bus.c                             |  3 +-
 drivers/dma-buf/dma-buf.c                     | 66 +++++++++++++------
 drivers/dma-buf/dma-resv.c                    |  6 +-
 drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c    |  4 +-
 drivers/gpio/gpio-mlxbf2.c                    |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c       |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c    | 12 ++--
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  3 +-
 drivers/gpu/drm/drm_file.c                    |  5 +-
 drivers/gpu/drm/drm_gem.c                     | 17 +++--
 drivers/gpu/drm/drm_gem_shmem_helper.c        | 42 ++++++++----
 drivers/gpu/drm/drm_gpusvm.c                  |  5 +-
 drivers/gpu/drm/drm_gpuvm.c                   |  4 +-
 drivers/gpu/drm/drm_mode_config.c             |  7 +-
 drivers/gpu/drm/drm_pagemap_util.c            |  2 +
 drivers/gpu/drm/drm_prime.c                   |  4 +-
 drivers/gpu/drm/gma500/gem.c                  | 10 ++-
 drivers/gpu/drm/i915/i915_vma.h               |  4 +-
 drivers/gpu/drm/imagination/pvr_gem.c         |  9 ++-
 drivers/gpu/drm/imagination/pvr_job.c         |  4 +-
 drivers/gpu/drm/imagination/pvr_vm.c          |  4 +-
 drivers/gpu/drm/lima/lima_gem.c               |  4 +-
 drivers/gpu/drm/loongson/lsdc_gem.c           |  6 +-
 drivers/gpu/drm/msm/msm_gem.h                 |  4 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c         | 14 ++--
 drivers/gpu/drm/nouveau/nouveau_prime.c       |  4 +-
 drivers/gpu/drm/nouveau/nouveau_uvmm.c        | 15 +++--
 drivers/gpu/drm/panfrost/panfrost_gem.c       | 10 ++-
 drivers/gpu/drm/panfrost/panfrost_mmu.c       |  4 +-
 drivers/gpu/drm/panthor/panthor_gem.c         | 10 ++-
 drivers/gpu/drm/panthor/panthor_mmu.c         |  7 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c               |  2 +-
 drivers/gpu/drm/radeon/radeon_prime.c         |  4 +-
 drivers/gpu/drm/ttm/tests/ttm_bo_test.c       | 39 +++++++----
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  |  7 +-
 drivers/gpu/drm/ttm/tests/ttm_resource_test.c |  4 +-
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c       | 15 +++--
 drivers/gpu/drm/ttm/ttm_bo.c                  |  9 ++-
 drivers/gpu/drm/vgem/vgem_fence.c             |  4 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c        | 11 ++--
 drivers/gpu/drm/virtio/virtgpu_prime.c        | 18 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_gem.c           |  4 +-
 drivers/gpu/drm/xe/xe_bo.c                    |  4 +-
 drivers/gpu/drm/xe/xe_ggtt.c                  |  2 +-
 drivers/gpu/drm/xe/xe_pm.c                    |  4 +-
 drivers/hwmon/gigabyte_waterforce.c           |  2 +-
 drivers/hwmon/it87.c                          |  4 +-
 drivers/hwmon/nzxt-kraken3.c                  |  2 +-
 drivers/infiniband/core/ib_core_uverbs.c      |  5 +-
 drivers/infiniband/core/umem_dmabuf.c         | 10 ++-
 .../infiniband/core/uverbs_std_types_dmabuf.c |  6 +-
 drivers/infiniband/hw/mlx5/mr.c               | 21 ++++--
 drivers/infiniband/hw/mlx5/odp.c              |  4 +-
 drivers/infiniband/ulp/srp/ib_srp.c           |  2 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c         |  4 +-
 drivers/input/rmi4/rmi_f54.c                  |  5 +-
 drivers/iommu/iommufd/pages.c                 | 10 ++-
 drivers/iommu/iommufd/selftest.c              |  4 +-
 drivers/leds/leds-blinkm.c                    |  2 +-
 drivers/md/md.c                               |  9 +--
 drivers/media/dvb-frontends/bcm3510.c         |  2 +-
 drivers/media/dvb-frontends/dib0070.c         |  4 +-
 drivers/media/dvb-frontends/dib0090.c         |  8 +--
 drivers/media/dvb-frontends/dib7000m.c        |  4 +-
 drivers/media/dvb-frontends/dib7000p.c        |  4 +-
 drivers/media/dvb-frontends/dib8000.c         | 10 +--
 drivers/media/dvb-frontends/dib9000.c         | 42 ++++++------
 drivers/media/dvb-frontends/dibx000_common.c  | 10 +--
 drivers/media/usb/dvb-usb-v2/af9035.c         |  2 +-
 drivers/media/usb/dvb-usb-v2/anysee.c         |  2 +-
 drivers/media/usb/dvb-usb-v2/au6610.c         |  2 +-
 drivers/media/usb/dvb-usb-v2/az6007.c         |  6 +-
 drivers/media/usb/dvb-usb-v2/ce6230.c         |  2 +-
 drivers/media/usb/dvb-usb-v2/dvbsky.c         |  2 +-
 drivers/media/usb/dvb-usb-v2/ec168.c          |  2 +-
 drivers/media/usb/dvb-usb-v2/lmedm04.c        |  2 +-
 drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c       |  2 +-
 drivers/media/usb/dvb-usb/af9005.c            |  2 +-
 drivers/media/usb/dvb-usb/az6027.c            |  2 +-
 drivers/media/usb/dvb-usb/cxusb.c             |  2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c      | 20 +++---
 drivers/media/usb/dvb-usb/dibusb-common.c     |  2 +-
 drivers/media/usb/dvb-usb/digitv.c            |  2 +-
 drivers/media/usb/dvb-usb/dtv5100.c           |  2 +-
 drivers/media/usb/dvb-usb/dvb-usb-urb.c       |  3 +-
 drivers/media/usb/dvb-usb/dw2102.c            | 16 ++---
 drivers/media/usb/dvb-usb/gp8psk.c            |  6 +-
 drivers/media/usb/dvb-usb/m920x.c             |  2 +-
 drivers/media/usb/dvb-usb/opera1.c            |  4 +-
 drivers/media/usb/dvb-usb/pctv452e.c          |  4 +-
 drivers/media/usb/dvb-usb/technisat-usb2.c    | 10 +--
 drivers/media/usb/dvb-usb/ttusb2.c            |  2 +-
 drivers/media/usb/dvb-usb/vp702x.c            |  5 +-
 .../media/usb/ttusb-budget/dvb-ttusb-budget.c |  4 +-
 drivers/media/usb/uvc/uvc_ctrl.c              |  6 +-
 drivers/misc/nsm.c                            |  2 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c     |  2 +-
 .../net/ethernet/broadcom/bnxt/bnxt_devlink.c |  2 +
 drivers/net/ethernet/intel/ice/ice_dcb_lib.c  |  4 +-
 .../ethernet/marvell/octeontx2/nic/otx2_pf.c  |  2 +-
 drivers/net/ethernet/mellanox/mlxsw/i2c.c     |  4 +-
 drivers/net/ethernet/qlogic/qed/qed_mcp.c     | 56 ++++++++--------
 drivers/net/mctp/mctp-i3c.c                   |  5 +-
 drivers/net/phy/mxl-86110.c                   |  2 +-
 drivers/net/usb/cdc_subset.c                  |  2 +-
 drivers/net/wireless/intersil/p54/p54usb.c    |  2 +-
 drivers/net/wireless/st/cw1200/pm.c           |  2 +
 drivers/net/wireless/ti/wlcore/main.c         |  4 +-
 drivers/net/wireless/ti/wlcore/sysfs.c        |  2 +-
 drivers/pci/setup-bus.c                       |  2 +-
 drivers/platform/x86/lenovo/thinkpad_acpi.c   | 12 ++--
 drivers/pnp/isapnp/core.c                     | 16 +++--
 drivers/scsi/fnic/fnic_scsi.c                 |  9 +--
 drivers/scsi/hpsa.c                           |  2 +-
 drivers/scsi/megaraid/megaraid_sas_base.c     | 15 +++--
 drivers/target/target_core_transport.c        |  2 +-
 drivers/tty/tty_io.c                          |  6 +-
 drivers/usb/class/cdc-wdm.c                   |  3 +-
 drivers/usb/class/usblp.c                     |  2 +-
 drivers/usb/class/usbtmc.c                    |  2 +-
 drivers/usb/core/message.c                    |  2 +-
 drivers/usb/core/sysfs.c                      | 24 +++----
 drivers/usb/gadget/legacy/inode.c             | 13 ++--
 drivers/usb/misc/yurex.c                      |  2 +-
 drivers/usb/storage/transport.c               |  2 +-
 drivers/usb/usb-skeleton.c                    |  2 +-
 drivers/usb/usbip/stub_dev.c                  | 21 ++++--
 drivers/usb/usbip/stub_main.c                 |  3 +-
 drivers/usb/usbip/stub_rx.c                   |  2 +-
 drivers/vfio/pci/vfio_pci_dmabuf.c            | 25 ++++---
 .../video/fbdev/omap2/omapfb/omapfb-ioctl.c   |  4 +-
 .../video/fbdev/omap2/omapfb/omapfb-main.c    |  4 +-
 .../video/fbdev/omap2/omapfb/omapfb-sysfs.c   |  4 +-
 drivers/video/fbdev/omap2/omapfb/omapfb.h     |  4 +-
 drivers/w1/masters/omap_hdq.c                 |  8 +--
 fs/afs/validation.c                           |  2 +-
 fs/afs/vl_alias.c                             |  6 +-
 fs/btrfs/extent_io.c                          |  1 +
 fs/cachefiles/namei.c                         |  1 -
 fs/f2fs/checkpoint.c                          |  8 ++-
 fs/f2fs/node.c                                |  8 ++-
 fs/fsopen.c                                   |  2 +-
 fs/orangefs/devorangefs-req.c                 |  2 +-
 fs/proc/base.c                                |  2 +-
 include/linux/codetag.h                       |  3 +-
 include/linux/dma-resv.h                      |  4 +-
 kernel/seccomp.c                              | 10 +--
 lib/alloc_tag.c                               |  8 +--
 lib/codetag.c                                 | 12 ++--
 mm/kmemleak.c                                 |  4 +-
 net/rxrpc/recvmsg.c                           |  2 +-
 net/rxrpc/sendmsg.c                           |  2 +-
 security/integrity/ima/ima_fs.c               |  2 +-
 sound/pci/oxygen/oxygen_lib.c                 |  2 +-
 160 files changed, 695 insertions(+), 443 deletions(-)

[PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Bart Van Assche]

The Clang thread-safety analyzer does not support comparing expressions
that use per_cpu(). Hence introduce a new local variable to capture the
address of a per-cpu spinlock. This patch prepares for enabling the
Clang thread-safety analyzer.

Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index 4a6d9a17da23..f8711b7b85a8 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
 	struct vcpu_vt *vt = to_vt(vcpu);
 	struct pi_desc old, new;
+	raw_spinlock_t *wakeup_lock;
 
 	lockdep_assert_irqs_disabled();
 
@@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	 * entirety of the sched_out critical section, i.e. the wakeup handler
 	 * can't run while the scheduler locks are held.
 	 */
-	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
-			     PI_LOCK_SCHED_OUT);
+	wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
+	raw_spin_lock_nested(wakeup_lock, PI_LOCK_SCHED_OUT);
 	list_add_tail(&vt->pi_wakeup_list,
 		      &per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
-	raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
+	raw_spin_unlock(wakeup_lock);
 
 	WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
 

[PATCH 02/62] blk-ioc: Prepare for enabling thread-safety analysis

[Bart Van Assche]

The Clang thread-safety analyzer does not support testing return values
with "< 0". Hence change the "< 0" test into "!= 0". This is fine since
the radix_tree_maybe_preload() return value is <= 0.

Cc: Jens Axboe <axboe@kernel.dk>
Cc: Yu Kuai <yukuai3@huawei.com>
Cc: Jan Kara <jack@suse.cz>
Cc: linux-block@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 block/blk-ioc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index d15918d7fabb..0bf78aebc887 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -364,7 +364,7 @@ static struct io_cq *ioc_create_icq(struct request_queue *q)
 	if (!icq)
 		return NULL;
 
-	if (radix_tree_maybe_preload(GFP_ATOMIC) < 0) {
+	if (radix_tree_maybe_preload(GFP_ATOMIC) != 0) {
 		kmem_cache_free(et->icq_cache, icq);
 		return NULL;
 	}

[PATCH 03/62] drbd: Balance RCU calls in drbd_adm_dump_devices()

[Bart Van Assche]

Make drbd_adm_dump_devices() call rcu_read_lock() before
rcu_read_unlock() is called. This has been detected by the Clang
thread-safety analyzer. Compile-tested only.

Cc: Andreas Gruenbacher <agruen@linbit.com>
Cc: linux-block@vger.kernel.org
Fixes: a55bbd375d18 ("drbd: Backport the "status" command")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/block/drbd/drbd_nl.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index e201f0087a0f..728ecc431b38 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -3378,8 +3378,10 @@ int drbd_adm_dump_devices(struct sk_buff *skb, struct netlink_callback *cb)
 		if (resource_filter) {
 			retcode = ERR_RES_NOT_KNOWN;
 			resource = drbd_find_resource(nla_data(resource_filter));
-			if (!resource)
+			if (!resource) {
+				rcu_read_lock();
 				goto put_result;
+			}
 			cb->args[0] = (long)resource;
 		}
 	}
@@ -3628,8 +3630,10 @@ int drbd_adm_dump_peer_devices(struct sk_buff *skb, struct netlink_callback *cb)
 		if (resource_filter) {
 			retcode = ERR_RES_NOT_KNOWN;
 			resource = drbd_find_resource(nla_data(resource_filter));
-			if (!resource)
+			if (!resource) {
+				rcu_read_lock();
 				goto put_result;
+			}
 		}
 		cb->args[0] = (long)resource;
 	}

[PATCH 04/62] dax/bus.c: Fix a locking bug

[Bart Van Assche]

Only unlock dax_dev_rwsem if it has been locked. This locking bug was
detected by the Clang thread-safety analyzer.

Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: nvdimm@lists.linux.dev
Cc: linux-cxl@vger.kernel.org
Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/dax/bus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index c94c09622516..ebd3806c34e5 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1117,11 +1117,10 @@ static ssize_t size_store(struct device *dev, struct device_attribute *attr,
 	}
 	rc = down_write_killable(&dax_dev_rwsem);
 	if (rc)
-		goto err_dev;
+		goto err_region;
 
 	rc = dev_dax_resize(dax_region, dev_dax, val);
 
-err_dev:
 	up_write(&dax_dev_rwsem);
 err_region:
 	up_write(&dax_region_rwsem);

[PATCH 05/62] dma-buf: Convert dma_buf_import_sync_file() to the early-return style

[Bart Van Assche]

Before making changes in dma_buf_import_sync_file(), convert it to
the early-return coding style. No functionality has been changed.

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/dma-buf/dma-buf.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 11711874a325..1666133ac8b8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -523,11 +523,13 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
 		dma_resv_lock(dmabuf->resv, NULL);
 
 		ret = dma_resv_reserve_fences(dmabuf->resv, num_fences);
-		if (!ret) {
-			dma_fence_unwrap_for_each(f, &iter, fence)
-				dma_resv_add_fence(dmabuf->resv, f, usage);
-		}
+		if (ret)
+			goto unlock;
+
+		dma_fence_unwrap_for_each(f, &iter, fence)
+			dma_resv_add_fence(dmabuf->resv, f, usage);
 
+unlock:
 		dma_resv_unlock(dmabuf->resv);
 	}
 

[PATCH 06/62] dma-buf: Handle all dma_resv_lock() errors

[Bart Van Assche]

Instead of assuming that dma_resv_lock() only returns 0 or -EDEADLK,
handle all possible dma_resv_lock() return values. This patch prepares
for enabling compile-time thread-safety analysis. This will cause the
compiler to check whether all dma_resv_lock() return values are handled.

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/dma-buf/dma-resv.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index bea3e9858aca..b4710f730e9b 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -792,6 +792,8 @@ static int __init dma_resv_lockdep(void)
 	ret = dma_resv_lock(&obj, &ctx);
 	if (ret == -EDEADLK)
 		dma_resv_lock_slow(&obj, &ctx);
+	else if (ret)
+		goto fini;
 	fs_reclaim_acquire(GFP_KERNEL);
 	/* for unmap_mapping_range on trylocked buffer objects in shrinkers */
 	i_mmap_lock_write(&mapping);
@@ -805,12 +807,14 @@ static int __init dma_resv_lockdep(void)
 #endif
 	fs_reclaim_release(GFP_KERNEL);
 	ww_mutex_unlock(&obj.lock);
+
+fini:
 	ww_acquire_fini(&ctx);
 	mmap_read_unlock(mm);
 
 	mmput(mm);
 
-	return 0;
+	return ret;
 }
 subsys_initcall(dma_resv_lockdep);
 #endif

[PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it

[Bart Van Assche]

Mutexes must be unlocked before these are destroyed. This has been detected
by the Clang thread-safety analyzer.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Yang Wang <kevinyang.wang@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
index afe5ca81beec..db7858fe0c3d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
@@ -641,6 +641,7 @@ static void aca_error_fini(struct aca_error *aerr)
 		aca_bank_error_remove(aerr, bank_error);
 
 out_unlock:
+	mutex_unlock(&aerr->lock);
 	mutex_destroy(&aerr->lock);
 }
 

[PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths

[Bart Van Assche]

Do not unlock psp->ras_context.mutex if it has not been locked. This has
been detected by the Clang thread-safety analyzer.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: YiPeng Chai <YiPeng.Chai@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
index 6e8aad91bcd3..0d3c18f04ac3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
@@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
 	if (!context || !context->initialized) {
 		dev_err(adev->dev, "TA is not initialized\n");
 		ret = -EINVAL;
-		goto err_free_shared_buf;
+		goto free_shared_buf;
 	}
 
 	if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
 		dev_err(adev->dev, "Unsupported function to invoke TA\n");
 		ret = -EOPNOTSUPP;
-		goto err_free_shared_buf;
+		goto free_shared_buf;
 	}
 
 	context->session_id = ta_id;
@@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
 	mutex_lock(&psp->ras_context.mutex);
 	ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
 	if (ret)
-		goto err_free_shared_buf;
+		goto unlock;
 
 	ret = psp_fn_ta_invoke(psp, cmd_id);
 	if (ret || context->resp_status) {
@@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
 			ret, context->resp_status);
 		if (!ret) {
 			ret = -EINVAL;
-			goto err_free_shared_buf;
+			goto unlock;
 		}
 	}
 
 	if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
 		ret = -EFAULT;
 
-err_free_shared_buf:
+unlock:
 	mutex_unlock(&psp->ras_context.mutex);
+
+free_shared_buf:
 	kfree(shared_buf);
 
 	return ret;

[PATCH 09/62] drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path

[Bart Van Assche]

Do not unlock mhdp->mbox_mutex if it has not been locked.

This bug has been detected by the Clang thread-safety analyzer.

Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Swapnil Jakhade <sjakhade@cadence.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 9392c226ff5b..ce4516de11d8 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -502,8 +502,7 @@ int cdns_mhdp_adjust_lt(struct cdns_mhdp_device *mhdp, unsigned int nlanes,
 
 	if (nlanes != 4 && nlanes != 2 && nlanes != 1) {
 		dev_err(mhdp->dev, "invalid number of lanes: %u\n", nlanes);
-		ret = -EINVAL;
-		goto out;
+		return -EINVAL;
 	}
 
 	payload[0] = nlanes;

[PATCH 10/62] drm: Make drm_read() easier to analyze

[Bart Van Assche]

Prepare for enabling the Clang thread-safety analyzer by duplicating a
return statement. No functionality has been changed.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/drm_file.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ec820686b302..200979d78452 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -572,8 +572,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer,
 			mutex_unlock(&file_priv->event_read_lock);
 			ret = wait_event_interruptible(file_priv->event_wait,
 						       !list_empty(&file_priv->event_list));
-			if (ret >= 0)
-				ret = mutex_lock_interruptible(&file_priv->event_read_lock);
+			if (ret < 0)
+				return ret;
+			ret = mutex_lock_interruptible(&file_priv->event_read_lock);
 			if (ret)
 				return ret;
 		} else {

[PATCH 11/62] drm/pagemap: Unlock cache->lock before freeing it

[Bart Van Assche]

Although freeing a spinlock without unlocking it is fine, this confuses
static analyzers. Hence this patch.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/drm_pagemap_util.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_pagemap_util.c b/drivers/gpu/drm/drm_pagemap_util.c
index 14ddb948a32e..50cb5f9cdac5 100644
--- a/drivers/gpu/drm/drm_pagemap_util.c
+++ b/drivers/gpu/drm/drm_pagemap_util.c
@@ -74,6 +74,8 @@ static void drm_pagemap_cache_fini(void *arg)
 		cache->dpagemap = NULL;
 		spin_unlock(&cache->lock);
 		drm_pagemap_destroy(dpagemap, false);
+	} else {
+		spin_unlock(&cache->lock);
 	}
 
 out:

[PATCH 12/62] drm/gpusvm.c: Fix a locking bug in an error path

[Bart Van Assche]

Only call drm_gpusvm_notifier_unlock() if drm_gpusvm_notifier_lock() was
called first. This has been detected by the Clang thread-safety
analyzer. Compile-tested only.

Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/drm_gpusvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
index 24180bfdf5a2..e9b79ab2f83c 100644
--- a/drivers/gpu/drm/drm_gpusvm.c
+++ b/drivers/gpu/drm/drm_gpusvm.c
@@ -819,7 +819,7 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
 
 		if (!(pfns[i] & HMM_PFN_VALID)) {
 			state = DRM_GPUSVM_SCAN_UNPOPULATED;
-			goto err_free;
+			goto unlock;
 		}
 
 		page = hmm_pfn_to_page(pfns[i]);
@@ -856,9 +856,10 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
 		i += 1ul << drm_gpusvm_hmm_pfn_to_order(pfns[i], i, npages);
 	}
 
-err_free:
+unlock:
 	drm_gpusvm_notifier_unlock(range->gpusvm);
 
+err_free:
 	kvfree(pfns);
 	return state;
 }

[PATCH 13/62] drm/qxl: Fix a buffer leak in an error path

[Bart Van Assche]

If qxl_bo_reserve() succeeds, call qxl_bo_unreserve() instead of
skipping that call.

This has been detected by the Clang thread-safety analyzer.
Compile-tested only.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux.dev
Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 4ee2b5acf2e0..5617811f3c9b 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -323,7 +323,7 @@ int qxl_update_area_ioctl(struct drm_device *dev, void *data, struct drm_file *f
 		qxl_ttm_placement_from_domain(qobj, qobj->type);
 		ret = ttm_bo_validate(&qobj->tbo, &qobj->placement, &ctx);
 		if (unlikely(ret))
-			goto out;
+			goto out2;
 	}
 
 	ret = qxl_bo_check_id(qdev, qobj);

[PATCH 14/62] hwmon: (it87) Check the it87_lock() return value

[Bart Van Assche]

Return early in it87_resume() if it87_lock() fails instead of ignoring the
return value of that function. This patch suppresses a Clang thread-safety
warning.

Cc: Frank Crawford <frank@crawford.emu.id.au>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: linux-hwmon@vger.kernel.org
Fixes: 376e1a937b30 ("hwmon: (it87) Add calls to smbus_enable/smbus_disable as required")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/hwmon/it87.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index e233aafa8856..8e3935089fca 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -3593,7 +3593,9 @@ static int it87_resume(struct device *dev)
 
 	it87_resume_sio(pdev);
 
-	it87_lock(data);
+	int err = it87_lock(data);
+	if (err)
+		return err;
 
 	it87_check_pwm(dev);
 	it87_check_limit_regs(data);

[PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path

[Bart Van Assche]

Lock f54->data_mutex before the first 'goto error' statement since
jumping to the 'error' label causes that mutex to be unlocked.

This bug has been detected by the Clang thread-safety checker.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>
Cc: linux-input@vger.kernel.org
Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/input/rmi4/rmi_f54.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index ac4041a69fcd..fd57ebb1cb50 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
 	int i;
 
 	report_size = rmi_f54_get_report_size(f54);
+
+	mutex_lock(&f54->data_mutex);
+
 	if (report_size == 0) {
 		dev_err(&fn->dev, "Bad report size, report type=%d\n",
 				f54->report_type);
@@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
 		goto error;     /* retry won't help */
 	}
 
-	mutex_lock(&f54->data_mutex);
-
 	/*
 	 * Need to check if command has completed.
 	 * If not try again later.

[PATCH 16/62] md: Make mddev_suspend() easier to analyze

[Bart Van Assche]

Prepare for enabling Clang's thread-safety analysis by moving an
if-statement. No functionality has been changed.

Cc: Song Liu <song@kernel.org>
Cc: Yu Kuai <yukuai@fnnas.com>
Cc: linux-raid@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/md/md.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3ce6f9e9d38e..b0d260d03a7d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -475,12 +475,13 @@ int mddev_suspend(struct mddev *mddev, bool interruptible)
 	 */
 	lockdep_assert_not_held(&mddev->reconfig_mutex);
 
-	if (interruptible)
+	if (interruptible) {
 		err = mutex_lock_interruptible(&mddev->suspend_mutex);
-	else
+		if (err)
+			return err;
+	} else {
 		mutex_lock(&mddev->suspend_mutex);
-	if (err)
-		return err;
+	}
 
 	if (mddev->suspended) {
 		WRITE_ONCE(mddev->suspended, mddev->suspended + 1);

[PATCH 17/62] bnxt_en: Make bnxt_resume() easier to analyze

[Bart Van Assche]

Pass the same argument to netdev_lock() and netdev_unlock(). This patch
prepares for enabling the Clang thread-safety analysis functionality. No
functional change intended.

Cc: Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index e062d5d400da..950708575268 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -17121,7 +17121,7 @@ static int bnxt_resume(struct device *device)
 	}
 
 resume_exit:
-	netdev_unlock(bp->dev);
+	netdev_unlock(dev);
 	bnxt_ulp_start(bp, rc);
 	if (!rc)
 		bnxt_reenable_sriov(bp);

[PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up()

[Bart Van Assche]

bnxt_dl_reload_down() calls rtnl_lock() and netdev_lock() if it returns
0. Hence, bnxt_dl_reload_up() should invoke the corresponding unlock
calls. This issue has been detected by the clang thread-sanitizer.
Compile-tested only.

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: netdev@vger.kernel.org
Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 15de802bbac4..1e9a3454bb29 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -562,6 +562,8 @@ static int bnxt_dl_reload_up(struct devlink *dl, enum devlink_reload_action acti
 		break;
 	}
 	default:
+		netdev_unlock(bp->dev);
+		rtnl_unlock();
 		return -EOPNOTSUPP;
 	}
 

[PATCH 19/62] ice: Fix a locking bug in an error path

[Bart Van Assche]

Move the mutex_lock() call up to prevent that DCB settings change after
the ice_query_port_ets() call.

This patch fixes a bug in an error path. Without this patch pf->tc_mutex
may be unlocked in an error path without having been locked. This bug has
been detected by the clang thread-safety analyzer.

Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Fixes: 242b5e068b25 ("ice: Fix DCB rebuild after reset")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
index bd77f1c001ee..78ded6876581 100644
--- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
@@ -537,14 +537,14 @@ void ice_dcb_rebuild(struct ice_pf *pf)
 	struct ice_dcbx_cfg *err_cfg;
 	int ret;
 
+	mutex_lock(&pf->tc_mutex);
+
 	ret = ice_query_port_ets(pf->hw.port_info, &buf, sizeof(buf), NULL);
 	if (ret) {
 		dev_err(dev, "Query Port ETS failed\n");
 		goto dcb_error;
 	}
 
-	mutex_lock(&pf->tc_mutex);
-
 	if (!pf->hw.port_info->qos_cfg.is_sw_lldp)
 		ice_cfg_etsrec_defaults(pf->hw.port_info);
 

Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path

[Dmitry Torokhov]

Hi Bart,

On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
> Lock f54->data_mutex before the first 'goto error' statement since
> jumping to the 'error' label causes that mutex to be unlocked.
> 
> This bug has been detected by the Clang thread-safety checker.
> 
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Nick Dyer <nick@shmanahar.org>
> Cc: linux-input@vger.kernel.org
> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>  drivers/input/rmi4/rmi_f54.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index ac4041a69fcd..fd57ebb1cb50 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
>  	int i;
>  
>  	report_size = rmi_f54_get_report_size(f54);
> +
> +	mutex_lock(&f54->data_mutex);
> +

Thank you for the patch. Do you mind if I move mutex_lock() above the
call to rmi_f54_get_report_size()? It does not extend critical section
by much, and I think logically makes more sense.

>  	if (report_size == 0) {
>  		dev_err(&fn->dev, "Bad report size, report type=%d\n",
>  				f54->report_type);
> @@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
>  		goto error;     /* retry won't help */
>  	}
>  
> -	mutex_lock(&f54->data_mutex);
> -
>  	/*
>  	 * Need to check if command has completed.
>  	 * If not try again later.

Thanks.

-- 
Dmitry

[PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Bart Van Assche]

From: Bart Van Assche <bvanassche@acm.org>

The Clang thread-safety analyzer does not support comparing expressions
that use per_cpu(). Hence introduce a new local variable to capture the
address of a per-cpu spinlock. This patch prepares for enabling the
Clang thread-safety analyzer.

Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index 4a6d9a17da23..f8711b7b85a8 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
 	struct vcpu_vt *vt = to_vt(vcpu);
 	struct pi_desc old, new;
+	raw_spinlock_t *wakeup_lock;
 
 	lockdep_assert_irqs_disabled();
 
@@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	 * entirety of the sched_out critical section, i.e. the wakeup handler
 	 * can't run while the scheduler locks are held.
 	 */
-	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
-			     PI_LOCK_SCHED_OUT);
+	wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
+	raw_spin_lock_nested(wakeup_lock, PI_LOCK_SCHED_OUT);
 	list_add_tail(&vt->pi_wakeup_list,
 		      &per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
-	raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
+	raw_spin_unlock(wakeup_lock);
 
 	WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
 

Re: [PATCH 00/62] Bug fixes and refactoring patches related to locking

[Peter Zijlstra]

On Mon, Feb 23, 2026 at 01:50:15PM -0800, Bart Van Assche wrote:
> Hi Peter,
> 
> Annotating all source files in the kernel tree with lock context annotations
> led to the discovery of a significant number of locking bugs. This patch
> series includes fixes for the discovered bugs. Additionally, multiple
> refactoring patches have been included that make it easier for the compiler
> to verify correctness of locking operations. Please consider this patch series
> for the next merge window.

Should we not rather have the various maintainers take the bits relevant
to them? This seems all rather orthogonal at this point.

Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path

[Bart Van Assche]

On 2/23/26 1:58 PM, Dmitry Torokhov wrote:
> Hi Bart,
> 
> On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
>> Lock f54->data_mutex before the first 'goto error' statement since
>> jumping to the 'error' label causes that mutex to be unlocked.
>>
>> This bug has been detected by the Clang thread-safety checker.
>>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: Nick Dyer <nick@shmanahar.org>
>> Cc: linux-input@vger.kernel.org
>> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>>   drivers/input/rmi4/rmi_f54.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
>> index ac4041a69fcd..fd57ebb1cb50 100644
>> --- a/drivers/input/rmi4/rmi_f54.c
>> +++ b/drivers/input/rmi4/rmi_f54.c
>> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
>>   	int i;
>>   
>>   	report_size = rmi_f54_get_report_size(f54);
>> +
>> +	mutex_lock(&f54->data_mutex);
>> +
> 
> Thank you for the patch. Do you mind if I move mutex_lock() above the
> call to rmi_f54_get_report_size()? It does not extend critical section
> by much, and I think logically makes more sense.

That sounds good to me. Please keep in mind that I'm not familiar with
the rmi4 driver.

Thanks,

Bart.

Re: [PATCH 00/62] Bug fixes and refactoring patches related to locking

[Bart Van Assche]

On 2/23/26 2:01 PM, Peter Zijlstra wrote:
> On Mon, Feb 23, 2026 at 01:50:15PM -0800, Bart Van Assche wrote:
>> Hi Peter,
>>
>> Annotating all source files in the kernel tree with lock context annotations
>> led to the discovery of a significant number of locking bugs. This patch
>> series includes fixes for the discovered bugs. Additionally, multiple
>> refactoring patches have been included that make it easier for the compiler
>> to verify correctness of locking operations. Please consider this patch series
>> for the next merge window.
> 
> Should we not rather have the various maintainers take the bits relevant
> to them? This seems all rather orthogonal at this point.

Hi Peter,

Agreed that this patch series can be split into multiple orthogonal
smaller series. However, splitting this series into multiple series,
looking up to which maintainer to send each series and keeping track of
the feedback on each series will significantly increase my workload.

BTW, none of the SMTP servers I tried so far allowed me to post the
entire patch series at once.

Thanks,

Bart.

Re: [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it

[Christian König]

On 2/23/26 22:50, Bart Van Assche wrote:
> Mutexes must be unlocked before these are destroyed. This has been detected
> by the Clang thread-safety analyzer.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Yang Wang <kevinyang.wang@amd.com>
> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>

Looks reasonable to me, but I'm not very familiar with this code. So only:

Acked-by: Christian König <christian.koenig@amd.com>

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> index afe5ca81beec..db7858fe0c3d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> @@ -641,6 +641,7 @@ static void aca_error_fini(struct aca_error *aerr)
>  		aca_bank_error_remove(aerr, bank_error);
>  
>  out_unlock:
> +	mutex_unlock(&aerr->lock);
>  	mutex_destroy(&aerr->lock);
>  }
>  

Re: [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths

[Christian König]

On 2/23/26 22:50, Bart Van Assche wrote:
> Do not unlock psp->ras_context.mutex if it has not been locked. This has
> been detected by the Clang thread-safety analyzer.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: YiPeng Chai <YiPeng.Chai@amd.com>
> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>

Acked-by: Christian König <christian.koenig@amd.com>

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> index 6e8aad91bcd3..0d3c18f04ac3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> @@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
>  	if (!context || !context->initialized) {
>  		dev_err(adev->dev, "TA is not initialized\n");
>  		ret = -EINVAL;
> -		goto err_free_shared_buf;
> +		goto free_shared_buf;
>  	}
>  
>  	if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
>  		dev_err(adev->dev, "Unsupported function to invoke TA\n");
>  		ret = -EOPNOTSUPP;
> -		goto err_free_shared_buf;
> +		goto free_shared_buf;
>  	}
>  
>  	context->session_id = ta_id;
> @@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
>  	mutex_lock(&psp->ras_context.mutex);
>  	ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
>  	if (ret)
> -		goto err_free_shared_buf;
> +		goto unlock;
>  
>  	ret = psp_fn_ta_invoke(psp, cmd_id);
>  	if (ret || context->resp_status) {
> @@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
>  			ret, context->resp_status);
>  		if (!ret) {
>  			ret = -EINVAL;
> -			goto err_free_shared_buf;
> +			goto unlock;
>  		}
>  	}
>  
>  	if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
>  		ret = -EFAULT;
>  
> -err_free_shared_buf:
> +unlock:
>  	mutex_unlock(&psp->ras_context.mutex);
> +
> +free_shared_buf:
>  	kfree(shared_buf);
>  
>  	return ret;

Re: [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths

[Alex Deucher]

Applied.  Thanks!

On Tue, Feb 24, 2026 at 3:54 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 2/23/26 22:50, Bart Van Assche wrote:
> > Do not unlock psp->ras_context.mutex if it has not been locked. This has
> > been detected by the Clang thread-safety analyzer.
> >
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: YiPeng Chai <YiPeng.Chai@amd.com>
> > Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> > Cc: amd-gfx@lists.freedesktop.org
> > Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
> > Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>
> Acked-by: Christian König <christian.koenig@amd.com>
>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > index 6e8aad91bcd3..0d3c18f04ac3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > @@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> >       if (!context || !context->initialized) {
> >               dev_err(adev->dev, "TA is not initialized\n");
> >               ret = -EINVAL;
> > -             goto err_free_shared_buf;
> > +             goto free_shared_buf;
> >       }
> >
> >       if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
> >               dev_err(adev->dev, "Unsupported function to invoke TA\n");
> >               ret = -EOPNOTSUPP;
> > -             goto err_free_shared_buf;
> > +             goto free_shared_buf;
> >       }
> >
> >       context->session_id = ta_id;
> > @@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> >       mutex_lock(&psp->ras_context.mutex);
> >       ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
> >       if (ret)
> > -             goto err_free_shared_buf;
> > +             goto unlock;
> >
> >       ret = psp_fn_ta_invoke(psp, cmd_id);
> >       if (ret || context->resp_status) {
> > @@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> >                       ret, context->resp_status);
> >               if (!ret) {
> >                       ret = -EINVAL;
> > -                     goto err_free_shared_buf;
> > +                     goto unlock;
> >               }
> >       }
> >
> >       if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
> >               ret = -EFAULT;
> >
> > -err_free_shared_buf:
> > +unlock:
> >       mutex_unlock(&psp->ras_context.mutex);
> > +
> > +free_shared_buf:
> >       kfree(shared_buf);
> >
> >       return ret;
>

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Sean Christopherson]

For the scope, please use:

   KVM: VMX:

On Mon, Feb 23, 2026, Bart Van Assche wrote:
> The Clang thread-safety analyzer does not support comparing expressions
> that use per_cpu(). Hence introduce a new local variable to capture the
> address of a per-cpu spinlock. This patch prepares for enabling the
> Clang thread-safety analyzer.
> 
> Cc: Sean Christopherson <seanjc@google.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: kvm@vger.kernel.org
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>  arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
> index 4a6d9a17da23..f8711b7b85a8 100644
> --- a/arch/x86/kvm/vmx/posted_intr.c
> +++ b/arch/x86/kvm/vmx/posted_intr.c
> @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>  	struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
>  	struct vcpu_vt *vt = to_vt(vcpu);
>  	struct pi_desc old, new;
> +	raw_spinlock_t *wakeup_lock;
>  
>  	lockdep_assert_irqs_disabled();
>  
> @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>  	 * entirety of the sched_out critical section, i.e. the wakeup handler
>  	 * can't run while the scheduler locks are held.
>  	 */
> -	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
> -			     PI_LOCK_SCHED_OUT);
> +	wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);

Addressing this piecemeal doesn't seem maintainable in the long term.  The odds
of unintentionally regressing the coverage with a cleanup are rather high.  Or
we'll end up with confused and/or grumpy developers because they're required to
write code in a very specific way because of what are effectively shortcomings
in the compiler.

> +	raw_spin_lock_nested(wakeup_lock, PI_LOCK_SCHED_OUT);
>  	list_add_tail(&vt->pi_wakeup_list,
>  		      &per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
> -	raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
> +	raw_spin_unlock(wakeup_lock);
>  
>  	WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
>  

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Bart Van Assche]

On 2/24/26 10:20 AM, Sean Christopherson wrote:
> For the scope, please use:
> 
>     KVM: VMX:
> 
> On Mon, Feb 23, 2026, Bart Van Assche wrote:
>> The Clang thread-safety analyzer does not support comparing expressions
>> that use per_cpu(). Hence introduce a new local variable to capture the
>> address of a per-cpu spinlock. This patch prepares for enabling the
>> Clang thread-safety analyzer.
>>
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: kvm@vger.kernel.org
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>>   arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
>> index 4a6d9a17da23..f8711b7b85a8 100644
>> --- a/arch/x86/kvm/vmx/posted_intr.c
>> +++ b/arch/x86/kvm/vmx/posted_intr.c
>> @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>>   	struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
>>   	struct vcpu_vt *vt = to_vt(vcpu);
>>   	struct pi_desc old, new;
>> +	raw_spinlock_t *wakeup_lock;
>>   
>>   	lockdep_assert_irqs_disabled();
>>   
>> @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>>   	 * entirety of the sched_out critical section, i.e. the wakeup handler
>>   	 * can't run while the scheduler locks are held.
>>   	 */
>> -	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
>> -			     PI_LOCK_SCHED_OUT);
>> +	wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
> 
> Addressing this piecemeal doesn't seem maintainable in the long term.  The odds
> of unintentionally regressing the coverage with a cleanup are rather high.  Or
> we'll end up with confused and/or grumpy developers because they're required to
> write code in a very specific way because of what are effectively shortcomings
> in the compiler.

I think it's worth mentioning that the number of patches similar to the
above is small. If I remember correctly, I only encountered two similar
cases in the entire kernel tree.

Regarding why the above patch is necessary, I don't think that it is
fair to blame the compiler in this case. The macros that implement
per_cpu() make it impossible for the compiler to conclude that the
pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
calls are identical:

/*
  * Add an offset to a pointer.  Use RELOC_HIDE() to prevent the compiler
  * from making incorrect assumptions about the pointer value.
  */
#define SHIFT_PERCPU_PTR(__p, __offset)				\
	RELOC_HIDE(PERCPU_PTR(__p), (__offset))

#define RELOC_HIDE(ptr, off)					\
({								\
	unsigned long __ptr;					\
	__asm__ ("" : "=r"(__ptr) : "0"(ptr));			\
	(typeof(ptr)) (__ptr + (off));				\
})

By the way, the above patch is not the only possible solution for
addressing the thread-safety warning Clang reports for this function. 
Another possibility is adding __no_context_analysis to the function
definition. Is the latter perhaps what you prefer?

Bart.

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Sean Christopherson]

On Tue, Feb 24, 2026, Bart Van Assche wrote:
> On 2/24/26 10:20 AM, Sean Christopherson wrote:
> > For the scope, please use:
> > 
> >     KVM: VMX:
> > 
> > On Mon, Feb 23, 2026, Bart Van Assche wrote:
> > > The Clang thread-safety analyzer does not support comparing expressions
> > > that use per_cpu(). Hence introduce a new local variable to capture the
> > > address of a per-cpu spinlock. This patch prepares for enabling the
> > > Clang thread-safety analyzer.
> > > 
> > > Cc: Sean Christopherson <seanjc@google.com>
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > > Cc: kvm@vger.kernel.org
> > > Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> > > ---
> > >   arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
> > >   1 file changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
> > > index 4a6d9a17da23..f8711b7b85a8 100644
> > > --- a/arch/x86/kvm/vmx/posted_intr.c
> > > +++ b/arch/x86/kvm/vmx/posted_intr.c
> > > @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> > >   	struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > >   	struct vcpu_vt *vt = to_vt(vcpu);
> > >   	struct pi_desc old, new;
> > > +	raw_spinlock_t *wakeup_lock;
> > >   	lockdep_assert_irqs_disabled();
> > > @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> > >   	 * entirety of the sched_out critical section, i.e. the wakeup handler
> > >   	 * can't run while the scheduler locks are held.
> > >   	 */
> > > -	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
> > > -			     PI_LOCK_SCHED_OUT);
> > > +	wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
> > 
> > Addressing this piecemeal doesn't seem maintainable in the long term.  The odds
> > of unintentionally regressing the coverage with a cleanup are rather high.  Or
> > we'll end up with confused and/or grumpy developers because they're required to
> > write code in a very specific way because of what are effectively shortcomings
> > in the compiler.
> 
> I think it's worth mentioning that the number of patches similar to the
> above is small. If I remember correctly, I only encountered two similar
> cases in the entire kernel tree.

Yeah, it's definitely not a deal-breaker to work around this in KVM, especially
if this is one of the few things blocking -Wthread-safety.

> Regarding why the above patch is necessary, I don't think that it is
> fair to blame the compiler in this case. The macros that implement
> per_cpu() make it impossible for the compiler to conclude that the
> pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
> calls are identical:

Well rats, that pretty much makes it infeasible to solve the underlying problem.

> /*
>  * Add an offset to a pointer.  Use RELOC_HIDE() to prevent the compiler
>  * from making incorrect assumptions about the pointer value.
>  */
> #define SHIFT_PERCPU_PTR(__p, __offset)				\
> 	RELOC_HIDE(PERCPU_PTR(__p), (__offset))
> 
> #define RELOC_HIDE(ptr, off)					\
> ({								\
> 	unsigned long __ptr;					\
> 	__asm__ ("" : "=r"(__ptr) : "0"(ptr));			\
> 	(typeof(ptr)) (__ptr + (off));				\
> })
> 
> By the way, the above patch is not the only possible solution for
> addressing the thread-safety warning Clang reports for this function.
> Another possibility is adding __no_context_analysis to the function
> definition. Is the latter perhaps what you prefer?

Hmm, I'd prefer to keep the analysis, even though it's a bit of a pain.  We already
went through quite some effort to preserve lockdep for this lock; compared to that,
forcing use of local variables is hardly anything.

My only concern is lack of enforcement and documentation.  I fiddled with a bunch
of ideas, but mostly of them flamed out because of the aformentioned lockdep
shenanigans.  E.g. forcing use of guard() or scoped_guard() doesn't Just Work.

The best idea I came up with is to rename the global variable to something scary,
and then define a CLASS() so that it's syntactically all but impossible to feed
the the result of per_cpu() directly into lock() or unlock().

What's your timeline for enabling -Wthread-safety?  E.g. are you trying to land
it in 7.1?  7.2+?  I'd be happy to formally post the below and get it landed in
the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
you're targeting 7.1).

---
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 26 Feb 2026 07:21:52 -0800
Subject: [PATCH] KVM: VMX: Force wakeup_vcpus_on_cpu_lock to be captured in
 local variable

Wrap wakeup_vcpus_on_cpu_lock in a CLASS() and append "do_not_use" to the
per-CPU symbol to effectively force lock()+unlock() paths to capture the
per-CPU lock in a local variable.  Clang's thread-safety analyzer doesn't
support comparing lock() vs. unlock() expressions that use separate
per_cpu() invocations (-Wthread-safety generates false-positves), as the
kernel's per_cpu() implementation deliberately hides the resolved address
from the compiler, specifically to prevent the compiler from reasoning
about the symbol.  I.e. per_cpu() is a victim of its own success.

Link: https://lore.kernel.org/all/a2ebde260608230500o3407b108hc03debb9da6e62c@mail.gmail.com
Link: https://news.ycombinator.com/item?id=18050983
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/vmx/posted_intr.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index 4a6d9a17da23..e08faaeab12f 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -31,7 +31,21 @@ static DEFINE_PER_CPU(struct list_head, wakeup_vcpus_on_cpu);
  * CPU.  IRQs must be disabled when taking this lock, otherwise deadlock will
  * occur if a wakeup IRQ arrives and attempts to acquire the lock.
  */
-static DEFINE_PER_CPU(raw_spinlock_t, wakeup_vcpus_on_cpu_lock);
+static DEFINE_PER_CPU(raw_spinlock_t, wakeup_vcpus_on_cpu_lock__do_not_touch);
+
+/*
+ * Route accesses to the lock through a CLASS() to effectively force users to
+ * capture the lock in a local variable.  The kernel's per_cpu() implementation
+ * deliberately obfuscates the address of the data to prevent the compiler from
+ * making incorrect assumptions about the symbol.  However, hiding the address
+ * triggers false-positive thread-safety warnings if lock() vs. unlock() are
+ * called with different per_cpu() invocations, because the compiler can't tell
+ * its the same lock under the hood.
+ */
+DEFINE_CLASS(pi_wakeup_vcpus_lock, raw_spinlock_t *,
+	     lockdep_assert_not_held(_T),
+	     &per_cpu(wakeup_vcpus_on_cpu_lock__do_not_touch, cpu),
+	     int cpu);
 
 #define PI_LOCK_SCHED_OUT SINGLE_DEPTH_NESTING
 
@@ -90,7 +104,7 @@ void vmx_vcpu_pi_load(struct kvm_vcpu *vcpu, int cpu)
 	 * current pCPU if the task was migrated.
 	 */
 	if (pi_desc->nv == POSTED_INTR_WAKEUP_VECTOR) {
-		raw_spinlock_t *spinlock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
+		CLASS(pi_wakeup_vcpus_lock, spinlock)(cpu);
 
 		/*
 		 * In addition to taking the wakeup lock for the regular/IRQ
@@ -165,6 +179,8 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	struct vcpu_vt *vt = to_vt(vcpu);
 	struct pi_desc old, new;
 
+	CLASS(pi_wakeup_vcpus_lock, spinlock)(vcpu->cpu);
+
 	lockdep_assert_irqs_disabled();
 
 	/*
@@ -179,11 +195,10 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
 	 * entirety of the sched_out critical section, i.e. the wakeup handler
 	 * can't run while the scheduler locks are held.
 	 */
-	raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
-			     PI_LOCK_SCHED_OUT);
+	raw_spin_lock_nested(spinlock, PI_LOCK_SCHED_OUT);
 	list_add_tail(&vt->pi_wakeup_list,
 		      &per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
-	raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
+	raw_spin_unlock(spinlock);
 
 	WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
 
@@ -254,9 +269,10 @@ void pi_wakeup_handler(void)
 {
 	int cpu = smp_processor_id();
 	struct list_head *wakeup_list = &per_cpu(wakeup_vcpus_on_cpu, cpu);
-	raw_spinlock_t *spinlock = &per_cpu(wakeup_vcpus_on_cpu_lock, cpu);
 	struct vcpu_vt *vt;
 
+	CLASS(pi_wakeup_vcpus_lock, spinlock)(cpu);
+
 	raw_spin_lock(spinlock);
 	list_for_each_entry(vt, wakeup_list, pi_wakeup_list) {
 
@@ -269,7 +285,7 @@ void pi_wakeup_handler(void)
 void __init pi_init_cpu(int cpu)
 {
 	INIT_LIST_HEAD(&per_cpu(wakeup_vcpus_on_cpu, cpu));
-	raw_spin_lock_init(&per_cpu(wakeup_vcpus_on_cpu_lock, cpu));
+	raw_spin_lock_init(&per_cpu(wakeup_vcpus_on_cpu_lock__do_not_touch, cpu));
 }
 
 void pi_apicv_pre_state_restore(struct kvm_vcpu *vcpu)

base-commit: 183bb0ce8c77b0fd1fb25874112bc8751a461e49
--

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Marco Elver]

On Thu, 26 Feb 2026 at 18:48, Sean Christopherson <seanjc@google.com> wrote:
> On Tue, Feb 24, 2026, Bart Van Assche wrote:
[...]
> > Regarding why the above patch is necessary, I don't think that it is
> > fair to blame the compiler in this case. The macros that implement
> > per_cpu() make it impossible for the compiler to conclude that the
> > pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
> > calls are identical:
>
> Well rats, that pretty much makes it infeasible to solve the underlying problem.
>
> > /*
> >  * Add an offset to a pointer.  Use RELOC_HIDE() to prevent the compiler
> >  * from making incorrect assumptions about the pointer value.
> >  */
> > #define SHIFT_PERCPU_PTR(__p, __offset)                               \
> >       RELOC_HIDE(PERCPU_PTR(__p), (__offset))
> >
> > #define RELOC_HIDE(ptr, off)                                  \
> > ({                                                            \
> >       unsigned long __ptr;                                    \
> >       __asm__ ("" : "=r"(__ptr) : "0"(ptr));                  \
> >       (typeof(ptr)) (__ptr + (off));                          \
> > })

There's a slim chance we can "fix" this with a similar approach as in:
https://lore.kernel.org/all/20260216142436.2207937-2-elver@google.com/
(specifically see patch 2/2)

The goal of RELOC_HIDE is to make the optimizer be less aggressive.
But the Thread Safety Analysis's alias analysis happens during
semantic analysis and is completely detached from the optimizer, and
we could potentially construct an expression that (a) lets Thread
Safety Analysis figure out that __ptr is an alias to ptr, while (b)
still hiding it from the optimizer. But I think we're sufficiently
scared of breaking (b) that I'm not sure if this is feasible in a
clean enough way that won't have other side-effects (e.g. worse
codegen).

If I find time I'll have a think unless someone beats me to it.

Thanks,
-- Marco

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Bart Van Assche]

On 2/26/26 9:47 AM, Sean Christopherson wrote:
> What's your timeline for enabling -Wthread-safety?  E.g. are you trying to land
> it in 7.1?  7.2+?  I'd be happy to formally post the below and get it landed in
> the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
> you're targeting 7.1).

Hi Sean,

I expect that I will need two or three release cycles to get all the 
patches upstream before -Wthread-safety can be enabled. How about
giving Marco a few weeks time to come up with an improvement for
RELOC_HIDE()?

Thanks,

Bart.

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Sean Christopherson]

On Thu, Feb 26, 2026, Bart Van Assche wrote:
> On 2/26/26 9:47 AM, Sean Christopherson wrote:
> > What's your timeline for enabling -Wthread-safety?  E.g. are you trying to land
> > it in 7.1?  7.2+?  I'd be happy to formally post the below and get it landed in
> > the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
> > you're targeting 7.1).
> 
> Hi Sean,
> 
> I expect that I will need two or three release cycles to get all the patches
> upstream before -Wthread-safety can be enabled. How about
> giving Marco a few weeks time to come up with an improvement for
> RELOC_HIDE()?

Works for me.  Thanks!

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Bart Van Assche]

On 2/26/26 12:13 PM, Marco Elver wrote:
> The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> But the Thread Safety Analysis's alias analysis happens during
> semantic analysis and is completely detached from the optimizer, and
> we could potentially construct an expression that (a) lets Thread
> Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> still hiding it from the optimizer. But I think we're sufficiently
> scared of breaking (b) that I'm not sure if this is feasible in a
> clean enough way that won't have other side-effects (e.g. worse
> codegen).

Does the thread-safety alias analyzer assume that function calls with
identical inputs produce identical outputs? If so, how about changing
RELOC_HIDE() from a macro into an inline function? Would that be
sufficient to make the thread-safety checker recognize identical
per_cpu() expressions as identical without affecting the behavior of the
optimizer?

Thanks,

Bart.

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Marco Elver]

On Thu, Feb 26, 2026 at 04:19PM -0800, Bart Van Assche wrote:
> On 2/26/26 12:13 PM, Marco Elver wrote:
> > The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> > But the Thread Safety Analysis's alias analysis happens during
> > semantic analysis and is completely detached from the optimizer, and
> > we could potentially construct an expression that (a) lets Thread
> > Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> > still hiding it from the optimizer. But I think we're sufficiently
> > scared of breaking (b) that I'm not sure if this is feasible in a
> > clean enough way that won't have other side-effects (e.g. worse
> > codegen).
> 
> Does the thread-safety alias analyzer assume that function calls with
> identical inputs produce identical outputs? If so, how about changing
> RELOC_HIDE() from a macro into an inline function? Would that be
> sufficient to make the thread-safety checker recognize identical
> per_cpu() expressions as identical without affecting the behavior of the
> optimizer?

The below works:

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index af16624b29fd..cb2f6050bdf7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -149,10 +149,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 #endif
 
 #ifndef RELOC_HIDE
-# define RELOC_HIDE(ptr, off)					\
-  ({ unsigned long __ptr;					\
-     __ptr = (unsigned long) (ptr);				\
-    (typeof(ptr)) (__ptr + (off)); })
+# define RELOC_HIDE(ptr, off) ((typeof(ptr))((unsigned long)(ptr) + (off)))
 #endif
 
 #define absolute_pointer(val)	RELOC_HIDE((void *)(val), 0)

That preserves original RELOC_HIDE intent (hide likely out-of-bounds
pointer calculation via unsigned long cast) - GCC has its own version of
RELOC_HIDE, so this seems to be exclusively for Clang.  For codegen, the
temporary variable was just optimized away, so I'm not sure what benefit
that indirection had at all. So all in all that should be equivalent to
before, and looks a lot cleaner.

The reason it works for Thread Safety Analysis is that TSA's alias
analysis strips away inner casts when resolving pointer aliases. Whereas
if there was an intermediate non-pointer (here: ulong) variable, it
stops.

Unless there are concerns, I'll send that as a patch.

Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze

[Marco Elver]

On Thu, 19 Mar 2026 at 00:31, Marco Elver <elver@google.com> wrote:
>
> On Thu, Feb 26, 2026 at 04:19PM -0800, Bart Van Assche wrote:
> > On 2/26/26 12:13 PM, Marco Elver wrote:
> > > The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> > > But the Thread Safety Analysis's alias analysis happens during
> > > semantic analysis and is completely detached from the optimizer, and
> > > we could potentially construct an expression that (a) lets Thread
> > > Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> > > still hiding it from the optimizer. But I think we're sufficiently
> > > scared of breaking (b) that I'm not sure if this is feasible in a
> > > clean enough way that won't have other side-effects (e.g. worse
> > > codegen).
> >
> > Does the thread-safety alias analyzer assume that function calls with
> > identical inputs produce identical outputs? If so, how about changing
> > RELOC_HIDE() from a macro into an inline function? Would that be
> > sufficient to make the thread-safety checker recognize identical
> > per_cpu() expressions as identical without affecting the behavior of the
> > optimizer?
>
> The below works:
[...]
> That preserves original RELOC_HIDE intent (hide likely out-of-bounds
> pointer calculation via unsigned long cast) - GCC has its own version of
> RELOC_HIDE, so this seems to be exclusively for Clang.  For codegen, the
> temporary variable was just optimized away, so I'm not sure what benefit
> that indirection had at all. So all in all that should be equivalent to
> before, and looks a lot cleaner.
>
> The reason it works for Thread Safety Analysis is that TSA's alias
> analysis strips away inner casts when resolving pointer aliases. Whereas
> if there was an intermediate non-pointer (here: ulong) variable, it
> stops.
>
> Unless there are concerns, I'll send that as a patch.

This should make the KVM code work as-is:
https://lore.kernel.org/all/20260319135245.1420780-1-elver@google.com/