Re: [PATCH] RDMA/mlx5: Add poll-EQ callback for ULP recovery

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rdma: ib_reap_eq() silently sleeps, causing schedule-while-atomic
--

commit 849787a8c3532fe1c3027a0b390b27451b5ded2d
Author: Praveen Kumar Kannoju <praveen.kannoju@oracle.com>

RDMA/mlx5: Add poll-EQ callback for ULP recovery

This commit introduces ib_reap_eq() as an optional RDMA device operation to
allow upper layer protocols (ULPs) to poll a completion event queue (EQ). It
implements this callback for mlx5 by mapping the CQ to its EQ and using
mlx5_eq_poll_irq_disabled() to poll it.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c

[ ... ]

> @@ -154,15 +154,36 @@ u32 mlx5_eq_poll_irq_disabled(struct mlx5_eq_comp *eq)
>  {
>  	u32 count_eqe;
>  
> +	mutex_lock(&eq->poll_lock);
> +	disable_irq(eq->core.irqn);

[Severity: High]
Could this lead to a scheduling while atomic panic or deadlock?

A ULP detecting a missed EQ notification might call ib_reap_eq() from an
atomic context, such as a timeout timer or while holding a spinlock.

The call chain reaches mlx5_eq_poll_irq_disabled(), which calls mutex_lock()
and disable_irq(). The disable_irq() function calls might_sleep() and
synchronously waits for running IRQ handlers.

[ ... ]

> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h

[ ... ]

> +/**
> + * ib_reap_eq - Poll the event queue associated with a CQ.
> + * @device: Device that owns the CQ.
> + * @cq: CQ whose associated event queue should be polled.
> + *
> + * Poll the device event queue associated with @cq to recover completions
> + * after a missed event queue notification. This is an optional provider
> + * callback.
> + *
> + * Return: 0 on success, %-EINVAL for invalid input, and %-EOPNOTSUPP when
> + * unsupported.
> + */
> +static inline int ib_reap_eq(struct ib_device *device, struct ib_cq *cq)
> +{
> +	if (!device || !cq || cq->device != device)
> +		return -EINVAL;
> +
> +	if (!device->ops.reap_eq)
> +		return -EOPNOTSUPP;
> +
> +	return device->ops.reap_eq(device, cq);

[Severity: High]
Since CQ polling and timeout mechanisms typically run in atomic contexts
(like softirq), does exposing this API without a might_sleep() check or
documentation risk ULPs misusing the API and crashing the system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100537.1214162-1-praveen.kannoju@oracle.com?part=1