[PATCH v1 0/5] Support Clang context analysis for RDMA/efa

[PATCH v1 0/5] Support Clang context analysis for RDMA/efa

[Timothy Day]

Hi,

This series adds annotations for Clang's context analysis to the
RDMA/efa driver.

Clang context analysis was recently added in a series by Marco
Elver [1]. This allows the compiler to validate different
locking patterns at compile time. This series enables context
analysis and adds new annotations.

The series was built with Clang 23 (since the minimum Clang
version for this feature was recently bumped to 23 in 7.2+ [2])
with CONFIG_WARN_CONTEXT_ANALYSIS enabled. I based this series
on rdma/for-next.

I'd appreciate reviews and suggestions. I'm especially interested
in suggestions on how we can make this easier to enable in other
parts of the rdma subsystem.

Thanks!

[1] https://lore.kernel.org/lkml/20251219154418.3592607-1-elver@google.com/
[2] https://lore.kernel.org/all/20260515124426.2227783-1-elver@google.com/

Timothy Day (5):
  RDMA/efa: mark mmio_read seq_num as guarded by mmio_read lock
  RDMA/efa: mark comp_ctx_pool* as guarded by comp_ctx_lock
  RDMA/efa: mark admin CQ consumer state as guarded by the ACQ lock
  RDMA/efa: mark admin SQ producer state as guarded by the ASQ lock
  RDMA/efa: enable context analysis support for efa driver

 drivers/infiniband/hw/efa/Makefile  |  2 ++
 drivers/infiniband/hw/efa/efa_com.c | 33 +++++++++++++++++------------
 drivers/infiniband/hw/efa/efa_com.h | 14 ++++++------
 3 files changed, 29 insertions(+), 20 deletions(-)

-- 
2.39.5

[PATCH v1 1/5] RDMA/efa: mark mmio_read seq_num as guarded by mmio_read lock

[Timothy Day]

seq_num is only ever accessed while holding the mmio_read lock,
so annotate it with __guarded_by() for Clang's context analysis.

The mmio_read lock initialisation in efa_com_mmio_reg_read_init()
is marked with guard(spinlock_init). This covers the mmio_read
seq_num initialisation (later in the function) that is done
before concurrent access is possible.

Signed-off-by: Timothy Day <timday@thelustrecollective.com>
---
 drivers/infiniband/hw/efa/efa_com.c | 2 +-
 drivers/infiniband/hw/efa/efa_com.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/efa/efa_com.c b/drivers/infiniband/hw/efa/efa_com.c
index 7097d1c2f23df..c48971595d5ef 100644
--- a/drivers/infiniband/hw/efa/efa_com.c
+++ b/drivers/infiniband/hw/efa/efa_com.c
@@ -956,7 +956,7 @@ int efa_com_mmio_reg_read_init(struct efa_com_dev *edev)
 {
 	struct efa_com_mmio_read *mmio_read = &edev->mmio_read;
 
-	spin_lock_init(&mmio_read->lock);
+	guard(spinlock_init)(&mmio_read->lock);
 	mmio_read->read_resp =
 		dma_alloc_coherent(edev->dmadev, sizeof(*mmio_read->read_resp),
 				   &mmio_read->read_resp_dma_addr, GFP_KERNEL);
diff --git a/drivers/infiniband/hw/efa/efa_com.h b/drivers/infiniband/hw/efa/efa_com.h
index 599db9d583bf5..cd1c68cdc5c43 100644
--- a/drivers/infiniband/hw/efa/efa_com.h
+++ b/drivers/infiniband/hw/efa/efa_com.h
@@ -99,7 +99,7 @@ struct efa_com_aenq {
 struct efa_com_mmio_read {
 	struct efa_admin_mmio_req_read_less_resp *read_resp;
 	dma_addr_t read_resp_dma_addr;
-	u16 seq_num;
+	u16 seq_num __guarded_by(&lock);
 	u16 mmio_read_timeout; /* usecs */
 	/* serializes mmio reads */
 	spinlock_t lock;
-- 
2.39.5

[PATCH v1 2/5] RDMA/efa: mark comp_ctx_pool* as guarded by comp_ctx_lock

[Timothy Day]

comp_ctx_pool and comp_ctx_pool_next are only ever accessed
while holding comp_ctx_lock (in efa_com_alloc_ctx_id() and
efa_com_dealloc_ctx_id()), so annotate comp_ctx_pool_next
with __guarded_by() and comp_ctx_pool with __pt_guarded_by()
for Clang's context analysis.

The comp_ctx_lock initialisation in efa_com_init_comp_ctxt()
is marked with guard(spinlock_init). It is moved earlier in the
function to cover both comp_ctx_pool and comp_ctx_pool_next
initialisation - that are both done before concurrent access
is possible.

Signed-off-by: Timothy Day <timday@thelustrecollective.com>
---
 drivers/infiniband/hw/efa/efa_com.c | 4 ++--
 drivers/infiniband/hw/efa/efa_com.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/hw/efa/efa_com.c b/drivers/infiniband/hw/efa/efa_com.c
index c48971595d5ef..4ef5ac363800d 100644
--- a/drivers/infiniband/hw/efa/efa_com.c
+++ b/drivers/infiniband/hw/efa/efa_com.c
@@ -386,6 +386,8 @@ static inline int efa_com_init_comp_ctxt(struct efa_com_admin_queue *aq)
 		return -ENOMEM;
 	}
 
+	guard(spinlock_init)(&aq->comp_ctx_lock);
+
 	for (i = 0; i < aq->depth; i++) {
 		comp_ctx = &aq->comp_ctx[i];
 		comp_ctx->status = EFA_CMD_UNUSED;
@@ -394,8 +396,6 @@ static inline int efa_com_init_comp_ctxt(struct efa_com_admin_queue *aq)
 		aq->comp_ctx_pool[i] = i;
 	}
 
-	spin_lock_init(&aq->comp_ctx_lock);
-
 	aq->comp_ctx_pool_next = 0;
 
 	return 0;
diff --git a/drivers/infiniband/hw/efa/efa_com.h b/drivers/infiniband/hw/efa/efa_com.h
index cd1c68cdc5c43..bf2c0a0f0d9e1 100644
--- a/drivers/infiniband/hw/efa/efa_com.h
+++ b/drivers/infiniband/hw/efa/efa_com.h
@@ -77,8 +77,8 @@ struct efa_com_admin_queue {
 	struct efa_com_stats_admin stats;
 
 	spinlock_t comp_ctx_lock; /* Protects completion context pool */
-	u32 *comp_ctx_pool;
-	u16 comp_ctx_pool_next;
+	u32 *comp_ctx_pool __pt_guarded_by(&comp_ctx_lock);
+	u16 comp_ctx_pool_next __guarded_by(&comp_ctx_lock);
 };
 
 struct efa_aenq_handlers;
-- 
2.39.5

[PATCH v1 3/5] RDMA/efa: mark admin CQ consumer state as guarded by the ACQ lock

[Timothy Day]

The admin completion queue consumer counter and phase bit are
accessed with the ACQ lock held. Annotate both fields with
__guarded_by() and annotate the completion handling helpers:

efa_com_handle_admin_completion()
efa_com_handle_single_admin_completion()
efa_com_cqe_checksum_valid()

with __must_hold() for Clang's context analysis.

The initialisation in efa_com_admin_init_cq() runs before the
admin queue is live. No concurrent access is possible. The
ACQ lock is marked guard(spinlock_init) to silence the context
analysis warning.

The prints in efa_com_wait_and_process_admin_cq_interrupts() are
diagnostics on the error path, where a racy read of the
consumer counter is acceptable. Since the lock isn't being taken,
wrap them in context_unsafe().

Signed-off-by: Timothy Day <timday@thelustrecollective.com>
---
 drivers/infiniband/hw/efa/efa_com.c | 10 +++++++---
 drivers/infiniband/hw/efa/efa_com.h |  4 ++--
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/efa/efa_com.c b/drivers/infiniband/hw/efa/efa_com.c
index 4ef5ac363800d..27be07e757e26 100644
--- a/drivers/infiniband/hw/efa/efa_com.c
+++ b/drivers/infiniband/hw/efa/efa_com.c
@@ -184,7 +184,7 @@ static int efa_com_admin_init_cq(struct efa_com_dev *edev)
 	if (!cq->entries)
 		return -ENOMEM;
 
-	spin_lock_init(&cq->lock);
+	guard(spinlock_init)(&cq->lock);
 
 	EFA_SET(&crc_min_ver, EFA_REGS_VERSION_MAJOR_VERSION, EFA_CRC_MIN_ADMIN_API_VERSION_MAJOR);
 	EFA_SET(&crc_min_ver, EFA_REGS_VERSION_MINOR_VERSION, EFA_CRC_MIN_ADMIN_API_VERSION_MINOR);
@@ -424,6 +424,7 @@ static int efa_com_submit_admin_cmd(struct efa_com_admin_queue *aq,
 
 static bool efa_com_cqe_checksum_valid(struct efa_com_admin_queue *aq,
 				       struct efa_admin_acq_entry *cqe)
+	__must_hold(&aq->cq.lock)
 {
 	u16 cqe_checksum = cqe->acq_common_descriptor.checksum;
 	u16 calc_checksum;
@@ -444,6 +445,7 @@ static bool efa_com_cqe_checksum_valid(struct efa_com_admin_queue *aq,
 
 static int efa_com_handle_single_admin_completion(struct efa_com_admin_queue *aq,
 						  struct efa_admin_acq_entry *cqe)
+	__must_hold(&aq->cq.lock)
 {
 	struct efa_comp_ctx *comp_ctx;
 	u16 cmd_id;
@@ -473,6 +475,7 @@ static int efa_com_handle_single_admin_completion(struct efa_com_admin_queue *aq
 }
 
 static void efa_com_handle_admin_completion(struct efa_com_admin_queue *aq)
+	__must_hold(&aq->cq.lock)
 {
 	struct efa_admin_acq_entry *cqe;
 	u16 queue_size_mask;
@@ -589,6 +592,7 @@ static int efa_com_wait_and_process_admin_cq_interrupts(struct efa_comp_ctx *com
 
 		atomic64_inc(&aq->stats.no_completion);
 
+		/* racy reads of the queue counters for diagnostics only */
 		if (comp_ctx->status == EFA_CMD_COMPLETED)
 			ibdev_err_ratelimited(
 				aq->efa_dev,
@@ -596,7 +600,7 @@ static int efa_com_wait_and_process_admin_cq_interrupts(struct efa_comp_ctx *com
 				efa_com_cmd_str(comp_ctx->cmd_opcode),
 				comp_ctx->cmd_opcode, comp_ctx->status,
 				comp_ctx->cmd_id, aq->sq.pc, aq->sq.cc,
-				aq->cq.cc);
+				context_unsafe(aq->cq.cc));
 		else
 			ibdev_err_ratelimited(
 				aq->efa_dev,
@@ -604,7 +608,7 @@ static int efa_com_wait_and_process_admin_cq_interrupts(struct efa_comp_ctx *com
 				efa_com_cmd_str(comp_ctx->cmd_opcode),
 				comp_ctx->cmd_opcode, comp_ctx->status,
 				comp_ctx->cmd_id, aq->sq.pc, aq->sq.cc,
-				aq->cq.cc);
+				context_unsafe(aq->cq.cc));
 
 		clear_bit(EFA_AQ_STATE_RUNNING_BIT, &aq->state);
 		return -ETIME;
diff --git a/drivers/infiniband/hw/efa/efa_com.h b/drivers/infiniband/hw/efa/efa_com.h
index bf2c0a0f0d9e1..39302559a7a98 100644
--- a/drivers/infiniband/hw/efa/efa_com.h
+++ b/drivers/infiniband/hw/efa/efa_com.h
@@ -28,8 +28,8 @@ struct efa_com_admin_cq {
 	spinlock_t lock; /* Protects ACQ */
 	bool validate_checksum;
 
-	u16 cc; /* consumer counter */
-	u8 phase;
+	u16 cc __guarded_by(&lock); /* consumer counter */
+	u8 phase __guarded_by(&lock);
 };
 
 struct efa_com_admin_sq {
-- 
2.39.5

[PATCH v1 4/5] RDMA/efa: mark admin SQ producer state as guarded by the ASQ lock

[Timothy Day]

The admin submission queue producer counter and phase bit are
accessed with the ASQ lock held. Annotate both fields with
__guarded_by() and __efa_com_submit_admin_cmd() with __must_hold()
for Clang's context analysis.

The initialisation in efa_com_admin_init_sq() runs before the
admin queue is live. No concurrent access is possible. The
ASQ lock is marked guard(spinlock_init) to silence the context
analysis warning.

The prints in efa_com_cqe_checksum_valid(),
efa_com_handle_single_admin_completion() and
efa_com_wait_and_process_admin_cq_interrupts() are diagnostics on
the error path, where a racy read of the producer counter is
acceptable. Since the lock isn't being taken, wrap them in
context_unsafe().

Signed-off-by: Timothy Day <timday@thelustrecollective.com>
---
 drivers/infiniband/hw/efa/efa_com.c | 21 ++++++++++++---------
 drivers/infiniband/hw/efa/efa_com.h |  4 ++--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/hw/efa/efa_com.c b/drivers/infiniband/hw/efa/efa_com.c
index 27be07e757e26..047b378f88045 100644
--- a/drivers/infiniband/hw/efa/efa_com.c
+++ b/drivers/infiniband/hw/efa/efa_com.c
@@ -148,7 +148,7 @@ static int efa_com_admin_init_sq(struct efa_com_dev *edev)
 	if (!sq->entries)
 		return -ENOMEM;
 
-	spin_lock_init(&sq->lock);
+	guard(spinlock_init)(&sq->lock);
 
 	sq->cc = 0;
 	sq->pc = 0;
@@ -329,6 +329,7 @@ static void __efa_com_submit_admin_cmd(struct efa_com_admin_queue *aq,
 				       size_t cmd_size_in_bytes,
 				       struct efa_admin_acq_entry *comp,
 				       size_t comp_size_in_bytes)
+	__must_hold(&aq->sq.lock)
 {
 	struct efa_admin_aq_entry *aqe;
 	u16 queue_size_mask;
@@ -433,10 +434,11 @@ static bool efa_com_cqe_checksum_valid(struct efa_com_admin_queue *aq,
 
 	calc_checksum = crc16(EFA_CRC16_INIT_VAL, (u8 *)cqe, sizeof(*cqe)) ^ EFA_CRC16_INIT_VAL;
 	if (calc_checksum != cqe_checksum) {
+		/* racy read of the SQ producer counter for diagnostics only */
 		ibdev_err(aq->efa_dev,
 			  "Received completion with invalid checksum, cqe[%u], calc[%u], sq producer[%d], sq consumer[%d], cq consumer[%d]\n",
-			  cqe_checksum, calc_checksum, aq->sq.pc, aq->sq.cc,
-			  aq->cq.cc);
+			  cqe_checksum, calc_checksum,
+			  context_unsafe(aq->sq.pc), aq->sq.cc, aq->cq.cc);
 		return false;
 	}
 
@@ -458,10 +460,11 @@ static int efa_com_handle_single_admin_completion(struct efa_com_admin_queue *aq
 
 	comp_ctx = efa_com_get_comp_ctx_by_cmd_id(aq, cmd_id);
 	if (comp_ctx->status != EFA_CMD_SUBMITTED || comp_ctx->cmd_id != cmd_id) {
+		/* racy read of the SQ producer counter for diagnostics only */
 		ibdev_err(aq->efa_dev,
 			  "Received completion with unexpected command id[%x], status[%d] sq producer[%d], sq consumer[%d], cq consumer[%d]\n",
-			  cmd_id, comp_ctx->status, aq->sq.pc, aq->sq.cc,
-			  aq->cq.cc);
+			  cmd_id, comp_ctx->status,
+			  context_unsafe(aq->sq.pc), aq->sq.cc, aq->cq.cc);
 		return -EINVAL;
 	}
 
@@ -599,16 +602,16 @@ static int efa_com_wait_and_process_admin_cq_interrupts(struct efa_comp_ctx *com
 				"The device sent a completion but the driver didn't receive any MSI-X interrupt for admin cmd %s(%d) status %d (id: %d, sq producer: %d, sq consumer: %d, cq consumer: %d)\n",
 				efa_com_cmd_str(comp_ctx->cmd_opcode),
 				comp_ctx->cmd_opcode, comp_ctx->status,
-				comp_ctx->cmd_id, aq->sq.pc, aq->sq.cc,
-				context_unsafe(aq->cq.cc));
+				comp_ctx->cmd_id, context_unsafe(aq->sq.pc),
+				aq->sq.cc, context_unsafe(aq->cq.cc));
 		else
 			ibdev_err_ratelimited(
 				aq->efa_dev,
 				"The device didn't send any completion for admin cmd %s(%d) status %d (id: %d, sq producer: %d, sq consumer: %d, cq consumer: %d)\n",
 				efa_com_cmd_str(comp_ctx->cmd_opcode),
 				comp_ctx->cmd_opcode, comp_ctx->status,
-				comp_ctx->cmd_id, aq->sq.pc, aq->sq.cc,
-				context_unsafe(aq->cq.cc));
+				comp_ctx->cmd_id, context_unsafe(aq->sq.pc),
+				aq->sq.cc, context_unsafe(aq->cq.cc));
 
 		clear_bit(EFA_AQ_STATE_RUNNING_BIT, &aq->state);
 		return -ETIME;
diff --git a/drivers/infiniband/hw/efa/efa_com.h b/drivers/infiniband/hw/efa/efa_com.h
index 39302559a7a98..2306666c86c80 100644
--- a/drivers/infiniband/hw/efa/efa_com.h
+++ b/drivers/infiniband/hw/efa/efa_com.h
@@ -40,8 +40,8 @@ struct efa_com_admin_sq {
 	u32 __iomem *db_addr;
 
 	u16 cc; /* consumer counter */
-	u16 pc; /* producer counter */
-	u8 phase;
+	u16 pc __guarded_by(&lock); /* producer counter */
+	u8 phase __guarded_by(&lock);
 
 };
 
-- 
2.39.5

[PATCH v1 5/5] RDMA/efa: enable context analysis support for efa driver

[Timothy Day]

Update efa Makefile to support context analysis [1].

[1] https://docs.kernel.org/dev-tools/context-analysis.html

Signed-off-by: Timothy Day <timday@thelustrecollective.com>
---
 drivers/infiniband/hw/efa/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/infiniband/hw/efa/Makefile b/drivers/infiniband/hw/efa/Makefile
index a6a433b0ba2f1..0a6843f3c5e1d 100644
--- a/drivers/infiniband/hw/efa/Makefile
+++ b/drivers/infiniband/hw/efa/Makefile
@@ -4,6 +4,8 @@
 # Makefile for Amazon Elastic Fabric Adapter (EFA) device driver.
 #
 
+CONTEXT_ANALYSIS := y
+
 obj-$(CONFIG_INFINIBAND_EFA) += efa.o
 
 efa-y := efa_com_cmd.o efa_ah_cache.o efa_com.o efa_main.o efa_verbs.o
-- 
2.39.5

Re: [PATCH v1 0/5] Support Clang context analysis for RDMA/efa

[Leon Romanovsky]

On Thu, Jul 16, 2026 at 11:16:53PM -0400, Timothy Day wrote:
> Hi,
> 
> This series adds annotations for Clang's context analysis to the
> RDMA/efa driver.
> 
> Clang context analysis was recently added in a series by Marco
> Elver [1]. This allows the compiler to validate different
> locking patterns at compile time. This series enables context
> analysis and adds new annotations.
> 
> The series was built with Clang 23 (since the minimum Clang
> version for this feature was recently bumped to 23 in 7.2+ [2])
> with CONFIG_WARN_CONTEXT_ANALYSIS enabled. I based this series
> on rdma/for-next.
> 
> I'd appreciate reviews and suggestions. I'm especially interested
> in suggestions on how we can make this easier to enable in other
> parts of the rdma subsystem.

Yes, this is precisely why I'm not rushing to apply it. It would
be far more compelling to first apply this context analysis to
drivers/infiniband/core, so we can evaluate both its benefits and
drawbacks.

On the other hand, converting drivers incrementally is the safer
approach.

Thanks

> 
> Thanks!
> 
> [1] https://lore.kernel.org/lkml/20251219154418.3592607-1-elver@google.com/
> [2] https://lore.kernel.org/all/20260515124426.2227783-1-elver@google.com/
> 
> Timothy Day (5):
>   RDMA/efa: mark mmio_read seq_num as guarded by mmio_read lock
>   RDMA/efa: mark comp_ctx_pool* as guarded by comp_ctx_lock
>   RDMA/efa: mark admin CQ consumer state as guarded by the ACQ lock
>   RDMA/efa: mark admin SQ producer state as guarded by the ASQ lock
>   RDMA/efa: enable context analysis support for efa driver
> 
>  drivers/infiniband/hw/efa/Makefile  |  2 ++
>  drivers/infiniband/hw/efa/efa_com.c | 33 +++++++++++++++++------------
>  drivers/infiniband/hw/efa/efa_com.h | 14 ++++++------
>  3 files changed, 29 insertions(+), 20 deletions(-)
> 
> -- 
> 2.39.5
> 

Re: [PATCH v1 0/5] Support Clang context analysis for RDMA/efa

[Timothy Day]

On Tue, 21 Jul 2026 14:10:30 +0300, Leon Romanovsky wrote:
> On Thu, Jul 16, 2026 at 11:16:53PM -0400, Timothy Day wrote:
> > Hi,
> >
> > This series adds annotations for Clang's context analysis to the
> > RDMA/efa driver.
> >
> > Clang context analysis was recently added in a series by Marco
> > Elver [1]. This allows the compiler to validate different
> > locking patterns at compile time. This series enables context
> > analysis and adds new annotations.
> >
> > The series was built with Clang 23 (since the minimum Clang
> > version for this feature was recently bumped to 23 in 7.2+ [2])
> > with CONFIG_WARN_CONTEXT_ANALYSIS enabled. I based this series
> > on rdma/for-next.
> >
> > I'd appreciate reviews and suggestions. I'm especially interested
> > in suggestions on how we can make this easier to enable in other
> > parts of the rdma subsystem.
>
> Yes, this is precisely why I'm not rushing to apply it. It would
> be far more compelling to first apply this context analysis to
> drivers/infiniband/core, so we can evaluate both its benefits and
> drawbacks.

That's fair - the context analysis work is still pretty new. There
are some examples in other subsystems. I submitted a series to
convert ext2 [1]. And there's some on-going work in the block layer
to enable this for nvme and other drivers [2].

> On the other hand, converting drivers incrementally is the safer
> approach.

The annotations should be a no-op without CONFIG_WARN_CONTEXT_ANALYSIS
enabled.

Generally, I'm looking for false positives/negatives in the
analysis and opportunities to create helper functions/macros
to reduce the amount of manual annotation required. I started
with smaller drivers to hopefully reduce the amount of churn
required for larger components. Also, core code tends to have
more complex locking patterns.

But I can prepare a series for core/, if there's interest
in reviewing it. We can also hold off a bit if you want to
wait for more adoption in other subsystems.

Tim Day

[1] https://lore.kernel.org/linux-fsdevel/20260712165610.366474-1-timday@thelustrecollective.com/
[2] https://lore.kernel.org/all/20260706141452.3008233-1-nilay@linux.ibm.com/

Re: [PATCH v1 0/5] Support Clang context analysis for RDMA/efa

[Leon Romanovsky]

On Tue, Jul 21, 2026 at 04:27:33PM -0400, Timothy Day wrote:
> On Tue, 21 Jul 2026 14:10:30 +0300, Leon Romanovsky wrote:
> > On Thu, Jul 16, 2026 at 11:16:53PM -0400, Timothy Day wrote:
> > > Hi,
> > >
> > > This series adds annotations for Clang's context analysis to the
> > > RDMA/efa driver.
> > >
> > > Clang context analysis was recently added in a series by Marco
> > > Elver [1]. This allows the compiler to validate different
> > > locking patterns at compile time. This series enables context
> > > analysis and adds new annotations.
> > >
> > > The series was built with Clang 23 (since the minimum Clang
> > > version for this feature was recently bumped to 23 in 7.2+ [2])
> > > with CONFIG_WARN_CONTEXT_ANALYSIS enabled. I based this series
> > > on rdma/for-next.
> > >
> > > I'd appreciate reviews and suggestions. I'm especially interested
> > > in suggestions on how we can make this easier to enable in other
> > > parts of the rdma subsystem.
> >
> > Yes, this is precisely why I'm not rushing to apply it. It would
> > be far more compelling to first apply this context analysis to
> > drivers/infiniband/core, so we can evaluate both its benefits and
> > drawbacks.
> 
> That's fair - the context analysis work is still pretty new. There
> are some examples in other subsystems. I submitted a series to
> convert ext2 [1]. And there's some on-going work in the block layer
> to enable this for nvme and other drivers [2].
> 
> > On the other hand, converting drivers incrementally is the safer
> > approach.
> 
> The annotations should be a no-op without CONFIG_WARN_CONTEXT_ANALYSIS
> enabled.
> 
> Generally, I'm looking for false positives/negatives in the
> analysis and opportunities to create helper functions/macros
> to reduce the amount of manual annotation required. I started
> with smaller drivers to hopefully reduce the amount of churn
> required for larger components. Also, core code tends to have
> more complex locking patterns.
> 
> But I can prepare a series for core/, if there's interest
> in reviewing it. We can also hold off a bit if you want to
> wait for more adoption in other subsystems.

We can try with core patches first.

Thanks

> 
> Tim Day
> 
> [1] https://lore.kernel.org/linux-fsdevel/20260712165610.366474-1-timday@thelustrecollective.com/
> [2] https://lore.kernel.org/all/20260706141452.3008233-1-nilay@linux.ibm.com/