All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Steve Siwinski <stevensiwinski@gmail.com>, hch@infradead.org
Cc: James.Bottomley@hansenpartnership.com, bgrove@atto.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	martin.petersen@oracle.com, ssiwinski@atto.com, axboe@kernel.dk,
	tdoedline@atto.com, linux-block@vger.kernel.org
Subject: Re: [PATCH v2] block, scsi: sd_zbc: Respect bio vector limits for report zones buffer
Date: Tue, 6 May 2025 11:29:08 +0900	[thread overview]
Message-ID: <32a7f1ad-e28a-4494-9293-96237c4ed70b@kernel.org> (raw)
In-Reply-To: <20250502193554.113928-1-ssiwinski@atto.com>

On 5/3/25 04:35, Steve Siwinski wrote:
> The report zones buffer size is currently limited by the HBA's
> maximum segment count to ensure the buffer can be mapped. However,
> the block layer further limits the number of iovec entries to
> 1024 when allocating a bio.
> 
> To avoid allocation of buffers too large to be mapped, further
> restrict the maximum buffer size to BIO_MAX_INLINE_VECS.
> 
> Replace the UIO_MAXIOV symbolic name with the more contextually
> appropriate BIO_MAX_INLINE_VECS.
> 
> Signed-off-by: Steve Siwinski <ssiwinski@atto.com>

This needs a "Fixes" tag:

Fixes: b091ac616846 ("sd_zbc: Fix report zones buffer allocation")
Cc: stable@vger.kernel.org

> diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
> index 7a447ff600d2..a5364fdc2824 100644
> --- a/drivers/scsi/sd_zbc.c
> +++ b/drivers/scsi/sd_zbc.c
> @@ -180,12 +180,15 @@ static void *sd_zbc_alloc_report_buffer(struct scsi_disk *sdkp,
>  	 * Furthermore, since the report zone command cannot be split, make
>  	 * sure that the allocated buffer can always be mapped by limiting the
>  	 * number of pages allocated to the HBA max segments limit.
> +	 * Since max segments can be larger than the max inline bio vectors,
> +	 * further limit the allocated buffer to BIO_MAX_INLINE_VECS.
>  	 */
>  	nr_zones = min(nr_zones, sdkp->zone_info.nr_zones);
>  	bufsize = roundup((nr_zones + 1) * 64, SECTOR_SIZE);
>  	bufsize = min_t(size_t, bufsize,
>  			queue_max_hw_sectors(q) << SECTOR_SHIFT);
>  	bufsize = min_t(size_t, bufsize, queue_max_segments(q) << PAGE_SHIFT);
> +	bufsize = min_t(size_t, bufsize, BIO_MAX_INLINE_VECS << PAGE_SHIFT);

I would prefer something like:

	unsigned int max_segments;
	...

	max_segments = min(BIO_MAX_INLINE_VECS, queue_max_segments(q));
	bufsize = min_t(size_t, bufsize, max_segments << PAGE_SHIFT);

>  
>  	while (bufsize >= SECTOR_SIZE) {
>  		buf = kvzalloc(bufsize, GFP_KERNEL | __GFP_NORETRY);
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index cafc7c215de8..7cf9506a6c36 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -11,6 +11,8 @@
>  #include <linux/uio.h>
>  
>  #define BIO_MAX_VECS		256U
> +/* BIO_MAX_INLINE_VECS must be at most the size of UIO_MAXIOV */
> +#define BIO_MAX_INLINE_VECS	1024

This should be:

#define BIO_MAX_INLINE_VECS	UIO_MAXIOV

so that we do not end up with inconsistencies with what user space sees as the
maximum value.

>  
>  struct queue_limits;
>  


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2025-05-06  2:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 20:36 [PATCH] scsi: sd_zbc: Limit the report zones buffer size to UIO_MAXIOV Steve Siwinski
2025-04-14  5:52 ` Christoph Hellwig
     [not found]   ` <OFA5AB0241.ED5C089D-ON85258C70.0068BDE0-85258C70.00721A7A@atto.com>
2025-04-18 21:29     ` Damien Le Moal
2025-04-24 15:33       ` Siwinski, Steve
2025-04-25  1:42         ` Damien Le Moal
2025-04-30 14:06           ` Christoph Hellwig
2025-05-02 19:35             ` [PATCH v2] block, scsi: sd_zbc: Respect bio vector limits for report zones buffer Steve Siwinski
2025-05-06  2:29               ` Damien Le Moal [this message]
2025-05-08 20:01                 ` [PATCH v3] " Steve Siwinski
2025-05-08 23:08                   ` Damien Le Moal

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=32a7f1ad-e28a-4494-9293-96237c4ed70b@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --cc=bgrove@atto.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ssiwinski@atto.com \
    --cc=stevensiwinski@gmail.com \
    --cc=tdoedline@atto.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.