All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Nilay Shroff <nilay@linux.ibm.com>, linux-block@vger.kernel.org
Cc: hch@lst.de, yukuai1@huaweicloud.com, hare@suse.de,
	ming.lei@redhat.com, axboe@kernel.dk, johannes.thumshirn@wdc.com,
	gjoyce@ibm.com
Subject: Re: [PATCHv3 2/2] null_blk: prevent submit and poll queues update for shared tagset
Date: Thu, 24 Jul 2025 08:53:30 +0900	[thread overview]
Message-ID: <5e56095c-bcf4-472c-941a-9580b0818c6c@kernel.org> (raw)
In-Reply-To: <20250723134442.1283664-3-nilay@linux.ibm.com>

On 7/23/25 22:43, Nilay Shroff wrote:
> When a user updates the number of submit or poll queues on a null_blk
> device, the block layer creates new hardware queues (hctxs). However, if
> the device is using a shared tagset, null_blk does not map any software
> queues (ctx) to the newly created hctx (via null_map_queues()), resulting
> in those hardware queues being left unused for I/O. This behavior is
> misleading, as the user may expect the new queues to be functional, even
> though they are effectively ignored. To avoid this confusion and potential
> misconfiguration:
> - Reject runtime updates to submit_queues or poll_queues via sysfs when
>   the device uses a shared tagset by returning -EINVAL.
> - During configuration validation (prior to powering on the device), reset
>   submit_queues and poll_queues to the module parameters (g_submit_queues
>   and g_poll_queues) if the shared tagset is enabled.
> 
> This ensures consistent behavior and avoids creating unused hardware queues
> (hctxs) due to ineffective runtime queue updates.
> 
> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research

  parent reply	other threads:[~2025-07-23 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23 13:43 [PATCHv3 0/2] fix sbitmap initialization and null_blk shared tagset behavior Nilay Shroff
2025-07-23 13:43 ` [PATCHv3 1/2] lib/sbitmap: fix kernel crash observed when sbitmap depth is zero Nilay Shroff
2025-07-24  2:19   ` Yu Kuai
2025-07-23 13:43 ` [PATCHv3 2/2] null_blk: prevent submit and poll queues update for shared tagset Nilay Shroff
2025-07-23 15:29   ` Hannes Reinecke
2025-07-23 23:53   ` Damien Le Moal [this message]
2025-07-24  2:21   ` Yu Kuai
2025-10-16 10:43 ` [PATCHv3 0/2] fix sbitmap initialization and null_blk shared tagset behavior Nilay Shroff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e56095c-bcf4-472c-941a-9580b0818c6c@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=gjoyce@ibm.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=nilay@linux.ibm.com \
    --cc=yukuai1@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.