Re: [PATCH 1/6] block: add queue_limits_start_update_trylock()

[Christoph Hellwig <hch@lst.de>]

On Mon, Sep 07, 2026 at 03:39:24PM +0200, Jack Wang wrote:
> From: Jack Wang <jinpu.wang@cloud.ionos.com>
> 
> Some callers must not wait for q->limits_lock, because they hold
> something the current holder waits for.  md is one: its
> check_sb_changes() runs with reconfig_mutex held, while a
> queue_attr_store() holding limits_lock waits in blk_mq_freeze_queue()
> for I/O that can be waiting for a superblock update needing that mutex.
> 
> Add a trylock variant of queue_limits_start_update() for them.

I don't think this is a good idea, please fix the lock ordering
instead.

> Assisted-by: Claude:claude-opus-5

But if not please try to come up with helpers like this based on
your own.  We don't really need this amount of AI slop.

> + * Like queue_limits_start_update(), but fails instead of waiting when another
> + * update is in flight.  For callers that must not block on q->limits_lock
> + * because they hold something its current owner is waiting for.
> + *
> + * Context: process context.
> + */
> +static inline bool
> +queue_limits_start_update_trylock(struct request_queue *q,
> +				  struct queue_limits *lim)
> +	__cond_acquires(true, &q->limits_lock)
> +{
> +	if (!mutex_trylock(&q->limits_lock))
> +		return false;
> +
> +	*lim = q->limits;
> +
> +	return true;
> +}
> +
>  int queue_limits_commit_update_frozen(struct request_queue *q,
>  		struct queue_limits *lim) __releases(&q->limits_lock);
>  int queue_limits_commit_update(struct request_queue *q,
> -- 
> 2.43.0
---end quoted text---