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

[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 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;
 	}
 

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

[Bart Van Assche via Intel-wired-lan]

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);
 

[PATCH 20/62] octeontx2-pf: Fix locking in an error path

[Bart Van Assche]

Only unlock pf->mbox.lock if it has been locked by otx2_do_set_vf_vlan().
This bug has been detected by the Clang thread-safety analyzer.

Cc: Naveen Mamindlapalli <naveenm@marvell.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Sunil Goutham <sgoutham@marvell.com>
Cc: Geetha sowjanya <gakula@marvell.com>
Cc: Subbaraya Sundeep <sbhatta@marvell.com>
Cc: hariprasad <hkelam@marvell.com>
Cc: Bharat Bhushan <bbhushan2@marvell.com>
Cc: netdev@vger.kernel.org
Fixes: f0c2982aaf98 ("octeontx2-pf: Add support for SR-IOV management functions")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
index ee623476e5ff..8c9f08ed90fd 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -2588,7 +2588,7 @@ static int otx2_do_set_vf_vlan(struct otx2_nic *pf, int vf, u16 vlan, u8 qos,
 	config = &pf->vf_configs[vf];
 
 	if (!vlan && !config->vlan)
-		goto out;
+		return err;
 
 	mutex_lock(&pf->mbox.lock);
 

[PATCH 21/62] qed: Make _qed_mcp_cmd_and_union() easier to analyze

[Bart Van Assche]

Make the implementation of this function compatible with clang's
compile-time thread-safety analysis by moving error-handling code to the
end of this function. No functionality has been changed.

Cc: Manish Chopra <manishc@marvell.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/ethernet/qlogic/qed/qed_mcp.c | 56 ++++++++++++-----------
 1 file changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 7e37fe631a58..462e758c5890 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -467,7 +467,7 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,
 	int rc = 0;
 
 	/* Wait until the mailbox is non-occupied */
-	do {
+	for (;;) {
 		/* Exit the loop if there is no pending command, or if the
 		 * pending command is completed during this iteration.
 		 * The spinlock stays locked until the command is sent.
@@ -486,18 +486,14 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,
 
 		spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
 
+		if (++cnt >= QED_DRV_MB_MAX_RETRIES)
+			goto retries_exceeded_1;
+
 		if (QED_MB_FLAGS_IS_SET(p_mb_params, CAN_SLEEP))
 			usleep_range(QED_MCP_RESP_ITER_US,
 				     QED_MCP_RESP_ITER_US * 2);
 		else
 			udelay(QED_MCP_RESP_ITER_US);
-	} while (++cnt < QED_DRV_MB_MAX_RETRIES);
-
-	if (cnt >= QED_DRV_MB_MAX_RETRIES) {
-		DP_NOTICE(p_hwfn,
-			  "The MFW mailbox is occupied by an uncompleted command. Failed to send command 0x%08x [param 0x%08x].\n",
-			  p_mb_params->cmd, p_mb_params->param);
-		return -EAGAIN;
 	}
 
 	/* Send the mailbox command */
@@ -513,7 +509,7 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,
 	spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
 
 	/* Wait for the MFW response */
-	do {
+	for (;;) {
 		/* Exit the loop if the command is already completed, or if the
 		 * command is completed during this iteration.
 		 * The spinlock stays locked until the list element is removed.
@@ -537,24 +533,9 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,
 			goto err;
 
 		spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
-	} while (++cnt < QED_DRV_MB_MAX_RETRIES);
-
-	if (cnt >= QED_DRV_MB_MAX_RETRIES) {
-		DP_NOTICE(p_hwfn,
-			  "The MFW failed to respond to command 0x%08x [param 0x%08x].\n",
-			  p_mb_params->cmd, p_mb_params->param);
-		qed_mcp_print_cpu_info(p_hwfn, p_ptt);
-
-		spin_lock_bh(&p_hwfn->mcp_info->cmd_lock);
-		qed_mcp_cmd_del_elem(p_hwfn, p_cmd_elem);
-		spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
 
-		if (!QED_MB_FLAGS_IS_SET(p_mb_params, AVOID_BLOCK))
-			qed_mcp_cmd_set_blocking(p_hwfn, true);
-
-		qed_hw_err_notify(p_hwfn, p_ptt,
-				  QED_HW_ERR_MFW_RESP_FAIL, NULL);
-		return -EAGAIN;
+		if (++cnt >= QED_DRV_MB_MAX_RETRIES)
+			goto retries_exceeded_2;
 	}
 
 	qed_mcp_cmd_del_elem(p_hwfn, p_cmd_elem);
@@ -576,6 +557,29 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,
 err:
 	spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
 	return rc;
+
+retries_exceeded_1:
+	DP_NOTICE(p_hwfn,
+		  "The MFW mailbox is occupied by an uncompleted command. Failed to send command 0x%08x [param 0x%08x].\n",
+		  p_mb_params->cmd, p_mb_params->param);
+	return -EAGAIN;
+
+retries_exceeded_2:
+	DP_NOTICE(p_hwfn,
+		  "The MFW failed to respond to command 0x%08x [param 0x%08x].\n",
+		  p_mb_params->cmd, p_mb_params->param);
+	qed_mcp_print_cpu_info(p_hwfn, p_ptt);
+
+	spin_lock_bh(&p_hwfn->mcp_info->cmd_lock);
+	qed_mcp_cmd_del_elem(p_hwfn, p_cmd_elem);
+	spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock);
+
+	if (!QED_MB_FLAGS_IS_SET(p_mb_params, AVOID_BLOCK))
+		qed_mcp_cmd_set_blocking(p_hwfn, true);
+
+	qed_hw_err_notify(p_hwfn, p_ptt,
+			  QED_HW_ERR_MFW_RESP_FAIL, NULL);
+	return -EAGAIN;
 }
 
 static int qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn,

[PATCH 22/62] mctp i3c: Fix locking in error paths

[Bart Van Assche]

Only unlock mi->lock if it has been locked. This bug has been detected by
the Clang thread-safety analyzer.

Cc: Leo Yang <Leo-Yang@quantatw.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: Matt Johnston <matt@codeconstruct.com.au>
Cc: netdev@vger.kernel.org
Fixes: 2d2d4f60ed26 ("mctp i3c: fix MCTP I3C driver multi-thread issue")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/net/mctp/mctp-i3c.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mctp/mctp-i3c.c b/drivers/net/mctp/mctp-i3c.c
index 6d2bbae7477b..d4a29912c7e1 100644
--- a/drivers/net/mctp/mctp-i3c.c
+++ b/drivers/net/mctp/mctp-i3c.c
@@ -112,7 +112,7 @@ static int mctp_i3c_read(struct mctp_i3c_device *mi)
 	if (!skb) {
 		stats->rx_dropped++;
 		rc = -ENOMEM;
-		goto err;
+		goto free_skb;
 	}
 
 	skb->protocol = htons(ETH_P_MCTP);
@@ -170,8 +170,11 @@ static int mctp_i3c_read(struct mctp_i3c_device *mi)
 
 	mutex_unlock(&mi->lock);
 	return 0;
+
 err:
 	mutex_unlock(&mi->lock);
+
+free_skb:
 	kfree_skb(skb);
 	return rc;
 }

[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 17/62] bnxt_en: Make bnxt_resume() easier to analyze

[Bart Van Assche]

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

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);

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

[Paul Menzel]

Dear Bart,


Thank you for the patch.

Am 23.02.26 um 22:49 schrieb Bart Van Assche:
> Prepare for enabling Clang's thread-safety analysis by moving an
> if-statement. No functionality has been changed.

Why does the if-statement need to be moved? Could you explain it in the 
commit message?

> 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);
> 


Kind regards,

Paul

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

[Michael Chan]

.
On Mon, Feb 23, 2026 at 1:52 PM Bart Van Assche <bvanassche@acm.org> wrote:
>
> 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();

This doesn't look correct.  The 2 locks are taken in
bnxt_dl_reload_down() only for the 2 actions
DEVLINK_RELOAD_ACTION_DRIVER_REINIT and
DEVLINK_RELOAD_ACTION_FW_ACTIVATE.  For the default action, no locks
are taken so I don't think we should unlock here.

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

[Jakub Kicinski]

On Mon, 23 Feb 2026 13:49:05 -0800 Bart Van Assche wrote:
> 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.

Please split out the 13(?) netdev patches to a separate series.
If you CC us on a subset of the series out CI will not test it.
Please keep in mind that we ask to wait at least 24h between
resubmissions
-- 
pw-bot: cr

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

[Jakub Kicinski]

On Mon, 23 Feb 2026 14:23:44 -0800 Jakub Kicinski wrote:
> On Mon, 23 Feb 2026 13:49:05 -0800 Bart Van Assche wrote:
> > 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.  
> 
> Please split out the 13(?) netdev patches to a separate series.
> If you CC us on a subset of the series out CI will not test it.
> Please keep in mind that we ask to wait at least 24h between
> resubmissions

Oh, not 13, 5, you already spammed us 3 times with this. Sigh.

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

[Bart Van Assche]

On 2/23/26 2:17 PM, Michael Chan wrote:
> .
> On Mon, Feb 23, 2026 at 1:52 PM Bart Van Assche <bvanassche@acm.org> wrote:
>>
>> 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();
> 
> This doesn't look correct.  The 2 locks are taken in
> bnxt_dl_reload_down() only for the 2 actions
> DEVLINK_RELOAD_ACTION_DRIVER_REINIT and
> DEVLINK_RELOAD_ACTION_FW_ACTIVATE.  For the default action, no locks
> are taken so I don't think we should unlock here.

Hi Michael,

My understanding is that bnxt_dl_reload_up() is only called if
bnxt_dl_reload_down() returns 0 (see also devlink_reload()).
bnxt_dl_reload_up() returns an error code (-EOPNOTSUPP) for other
actions than DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
DEVLINK_RELOAD_ACTION_FW_ACTIVATE. Hence, bnxt_dl_reload_up() is only
called if "action" is either DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
DEVLINK_RELOAD_ACTION_FW_ACTIVATE. In other words, the code in the
"default" clause will never be reached. So I think the above change is
correct but also that the patch description should be modified to
reflect that this is not a bug fix. Did I perhaps misunderstand
something?

Thanks,

Bart.

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

[Bart Van Assche]

On 2/23/26 2:24 PM, Jakub Kicinski wrote:
> Oh, not 13, 5, you already spammed us 3 times with this. Sigh.

Sorry for the spam. I have not yet found an SMTP server that can post
the entire patch series without reporting an error message halfway.

smtpauth.mailroute.net reported "quota exceeded" while
smtp.migadu.com reported "4.7.1 Error: too many recipients from 
2a00:79e0:2e7c:8:b343:b0de:3e59:4e65".

Bart.

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

[Michael Chan]

On Mon, Feb 23, 2026 at 2:27 PM Bart Van Assche
<bart.vanassche@gmail.com> wrote:

> My understanding is that bnxt_dl_reload_up() is only called if
> bnxt_dl_reload_down() returns 0 (see also devlink_reload()).
> bnxt_dl_reload_up() returns an error code (-EOPNOTSUPP) for other
> actions than DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. Hence, bnxt_dl_reload_up() is only
> called if "action" is either DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. In other words, the code in the
> "default" clause will never be reached. So I think the above change is
> correct but also that the patch description should be modified to
> reflect that this is not a bug fix. Did I perhaps misunderstand
> something?
>
Yes, your description is correct.  So perhaps a better cleanup would
be to remove the default case in bnxt_dl_reload_up()?  Thanks.

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

[Bart Van Assche]

On 2/23/26 2:37 PM, Michael Chan wrote:
> On Mon, Feb 23, 2026 at 2:27 PM Bart Van Assche
> <bart.vanassche@gmail.com> wrote:
> 
>> My understanding is that bnxt_dl_reload_up() is only called if
>> bnxt_dl_reload_down() returns 0 (see also devlink_reload()).
>> bnxt_dl_reload_up() returns an error code (-EOPNOTSUPP) for other
>> actions than DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
>> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. Hence, bnxt_dl_reload_up() is only
>> called if "action" is either DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
>> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. In other words, the code in the
>> "default" clause will never be reached. So I think the above change is
>> correct but also that the patch description should be modified to
>> reflect that this is not a bug fix. Did I perhaps misunderstand
>> something?
>>
> Yes, your description is correct.  So perhaps a better cleanup would
> be to remove the default case in bnxt_dl_reload_up()?  Thanks.

Hmm ... wouldn't that trigger a -Wswitch warning, a warning that is
enabled by default for kernel code? From the gcc documentation:
"Warn whenever a switch statement has an index of enumerated type and
lacks a case for one or more of the named codes of that enumeration.
(The presence of a default label prevents this warning.) case labels
that do not correspond to enumerators also provoke warnings when this
option is used, unless the enumeration is marked with the flag_enum
attribute. This warning is enabled by -Wall."

Changing "default: return -EOPNOTSUPP;" into "default: BUG();" keeps
the Clang thread-sanitizer happy but does not comply with the kernel
coding style. Does the patch below look better?

Thanks,

Bart.

bnxt_en: Suppress thread-safety complaints about bnxt_dl_reload_up()

bnxt_dl_reload_down() returns an error code for actions that are not
supported. Hence, bnxt_dl_reload_up() won't be called for unsupported
actions. Since the compiler doesn't know this, add unlock calls to the
default clause. This patch suppresses a Clang thread-sanitizer
complaint. 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>

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 15de802bbac4..aa7ebd1426ed 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -562,6 +562,13 @@ static int bnxt_dl_reload_up(struct devlink *dl, 
enum devlink_reload_action acti
  		break;
  	}
  	default:
+		/*
+		 * Other actions have already been rejected by
+		 * bnxt_dl_reload_down().
+		 */
+		WARN_ON_ONCE(true);
+		netdev_unlock(bp->dev);
+		rtnl_unlock();
  		return -EOPNOTSUPP;
  	}

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

[Michael Chan]

On Mon, Feb 23, 2026 at 2:56 PM Bart Van Assche
<bart.vanassche@gmail.com> wrote:

> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> index 15de802bbac4..aa7ebd1426ed 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> @@ -562,6 +562,13 @@ static int bnxt_dl_reload_up(struct devlink *dl,
> enum devlink_reload_action acti
>                 break;
>         }
>         default:
> +               /*
> +                * Other actions have already been rejected by
> +                * bnxt_dl_reload_down().
> +                */
> +               WARN_ON_ONCE(true);
> +               netdev_unlock(bp->dev);
> +               rtnl_unlock();

This is better.  It makes it clear that it should never get here.

>                 return -EOPNOTSUPP;
>         }
>
>

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

[Christian König]

On 2/23/26 22:48, Bart Van Assche wrote:
> 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);

Mhm, I don't see what this is good for?

While this might look a little bit nicer we don't enforce this coding style and it adds more loc.

Regards,
Christian.

> 
> +unlock:
>                 dma_resv_unlock(dmabuf->resv);
>         }
> 

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

[Christian König]

On 2/23/26 22:48, Bart Van Assche wrote:
> 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;

Mhm, that looks a bit questionable to me. Only checking for EDEADLK was intentional.

>         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;

Oh! This is an *absolutely* clear NAK for that change.

This code here is to only improve debugging messages, so it's not problematic at all if it fails.

If I'm not completely mistaken if you return the error code the whole kernel would fail to boot *and* we have a random error injection feature for testing which makes it returning an error randomly!

So this change here would result in randomly not booting kernels and that is something we seriously can't do :)

We could add code which prints and error if ret is something else than 0 or EDEADLK, but that case is already covered by the selftests and so would be 100% dead code.

Why exactly do you need that? Would a code comment explaining the background be helpful?

Regards,
Christian.

>  }
>  subsys_initcall(dma_resv_lockdep);
>  #endif

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

[Christoph Hellwig]

On Mon, Feb 23, 2026 at 01:48:50PM -0800, Bart Van Assche wrote:
> 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.

This is a series with 62 patches, of which only some and not the cover
letter made it to linux-block.  You're doing something seriously
wrong in your patch submission.

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

[Christoph Böhmwalder]

Am 23.02.26 um 22:48 schrieb 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;
>  	}
> 

Passes our internal DRBD test suite.

Tested-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

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

[Bart Van Assche]

On 2/24/26 12:20 AM, Christian König wrote:
> Why exactly do you need that? Would a code comment explaining the
> background be helpful?
dma_resv_lock() has been annotated with	__cond_acquires(0, &obj->lock)
and dma_resv_unlock() has been annotated with __releases(&obj->lock).
Hence, with thread-safety analysis enabled, Clang complains about
dma_resv_unlock() calls if dma_resv_lock() returns an error code. There
are several possibilities for suppressing Clang's thread-
safety warnings:
* The least elegant is to annotate dma_resv_lockdep() with
   __no_context_analysis and to add a comment.
* A better option is to rework the code such that dma_resv_unlock() is
   not called if dma_resv_lock() returns an error code. That is what I
   tried to do. There may be better alternatives than my patch.

Thanks,

Bart.

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

[Bart Van Assche]

On 2/24/26 6:45 AM, Christoph Hellwig wrote:
> This is a series with 62 patches, of which only some and not the cover
> letter made it to linux-block.  You're doing something seriously
> wrong in your patch submission.

The two SMTP servers that I tried (smtpauth.mailroute.net and
smtp.migadu.com) gave up about halfway this patch series (quota
exceeded / too many recipients).

Peter Zijlstra asked me to split this series and to send the patches 
from this series directly to the maintainers of the affected code rather
than to send these patches as one large patch series to him.

Thanks,

Bart.

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

[Christian König]

Hi Bart,

On 2/24/26 18:28, Bart Van Assche wrote:
> On 2/24/26 12:20 AM, Christian König wrote:
>> Why exactly do you need that? Would a code comment explaining the
>> background be helpful?
> dma_resv_lock() has been annotated with    __cond_acquires(0, &obj->lock)
> and dma_resv_unlock() has been annotated with __releases(&obj->lock).
> Hence, with thread-safety analysis enabled, Clang complains about
> dma_resv_unlock() calls if dma_resv_lock() returns an error code. There
> are several possibilities for suppressing Clang's thread-
> safety warnings:
> * The least elegant is to annotate dma_resv_lockdep() with
>   __no_context_analysis and to add a comment.

Yeah, that is clearly a bad idea.

There are basically only two places were we have to ignore this:

1. The dma_resv_lockdep() function you stumbled over.

2. Some selftest we used to have which intentionally got it wrong to check if lockdep correctly complains about it.
   (You most likely already excluded that somehow).

Every other code should definitely have this analysis.

Is it somehow possible to annotate only the dma_resv_lockdep() function?

> * A better option is to rework the code such that dma_resv_unlock() is
>   not called if dma_resv_lock() returns an error code. That is what I
>   tried to do. There may be better alternatives than my patch.

That would be dead code which is never used at all and only there to silence the warning. That is usually also a rather bad idea.

Would it help if we change the code like this?

        ret = dma_resv_lock(&obj, &ctx);
-       if (ret == -EDEADLK)
+       /* Only EDEADLK from the error injection is possible here */
+       if (ret)
                dma_resv_lock_slow(&obj, &ctx);

Thanks,
Christian.

> 
> Thanks,
> 
> Bart.

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

[Bart Van Assche]

On 2/25/26 12:16 AM, Christian König wrote:
> Would it help if we change the code like this?
> 
>          ret = dma_resv_lock(&obj, &ctx);
> -       if (ret == -EDEADLK)
> +       /* Only EDEADLK from the error injection is possible here */
> +       if (ret)
>                  dma_resv_lock_slow(&obj, &ctx);

Yes, the above is sufficient to suppress the Clang thread-safety warning
for dma_resv_lockdep(). Is a source code comment about EDEADLK preferred
or would the following perhaps also be acceptable?

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index bea3e9858aca..4d65dddbcbdf 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -790,8 +790,10 @@ static int __init dma_resv_lockdep(void)
         mmap_read_lock(mm);
         ww_acquire_init(&ctx, &reservation_ww_class);
         ret = dma_resv_lock(&obj, &ctx);
-       if (ret == -EDEADLK)
+       if (ret) {
+               WARN_ON_ONCE(ret != -EDEADLK);
                 dma_resv_lock_slow(&obj, &ctx);
+       }
         fs_reclaim_acquire(GFP_KERNEL);
         /* for unmap_mapping_range on trylocked buffer objects in 
shrinkers */
         i_mmap_lock_write(&mapping);

Thanks,

Bart.

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

[Bart Van Assche]

On 2/23/26 11:56 PM, Christian König wrote:
> On 2/23/26 22:48, Bart Van Assche wrote:
>> 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);
> 
> Mhm, I don't see what this is good for?
> 
> While this might look a little bit nicer we don't enforce this coding style and it adds more loc.

Hi Christian,

I will drop this change.

Thanks,

Bart.

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

[Christian König]

On 2/25/26 22:36, Bart Van Assche wrote:
> On 2/25/26 12:16 AM, Christian König wrote:
>> Would it help if we change the code like this?
>>
>>          ret = dma_resv_lock(&obj, &ctx);
>> -       if (ret == -EDEADLK)
>> +       /* Only EDEADLK from the error injection is possible here */
>> +       if (ret)
>>                  dma_resv_lock_slow(&obj, &ctx);
> 
> Yes, the above is sufficient to suppress the Clang thread-safety warning
> for dma_resv_lockdep().

Cool, then let us use this approach here.

> Is a source code comment about EDEADLK preferred
> or would the following perhaps also be acceptable?

I think the warning is optional, but potentially good to have as well.

But the code comment is mandatory, otherwise we will have forgotten in 10 years why exactly only EDEADLK can happen here.

> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index bea3e9858aca..4d65dddbcbdf 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -790,8 +790,10 @@ static int __init dma_resv_lockdep(void)
>         mmap_read_lock(mm);
>         ww_acquire_init(&ctx, &reservation_ww_class);
>         ret = dma_resv_lock(&obj, &ctx);
> -       if (ret == -EDEADLK)
> +       if (ret) {
> +               WARN_ON_ONCE(ret != -EDEADLK);

Please make that only WARN_ON(). I would be massively surprised when a subsystem initcall executes more than once.

Thanks,
Christian.

>                 dma_resv_lock_slow(&obj, &ctx);
> +       }
>         fs_reclaim_acquire(GFP_KERNEL);
>         /* for unmap_mapping_range on trylocked buffer objects in shrinkers */
>         i_mmap_lock_write(&mapping);
> 
> Thanks,
> 
> Bart.