All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Hans Holmberg <hans.holmberg@wdc.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Christoph Hellwig <hch@lst.de>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Andreas Hindborg <a.hindborg@kernel.org>
Subject: Re: [PATCH] null_blk: set dma alignment to logical block size
Date: Wed, 29 Oct 2025 08:12:15 -0600	[thread overview]
Message-ID: <aQIgvwec4Ol7ed8K@kbusch-mbp> (raw)
In-Reply-To: <20251029133956.19554-1-hans.holmberg@wdc.com>

On Wed, Oct 29, 2025 at 02:39:56PM +0100, Hans Holmberg wrote:
> This driver assumes that bio vectors are memory aligned to the logical
> block size, so set the queue limit to reflect that.
> 
> Unless we set up the limit based on the logical block size, we will go
> out of page bounds in copy_to_nullb / copy_from_nullb.
> 
> Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
> ---
> 
> A fixes tag would be in order, but I have not figured out exactly when
> this became a problem.

Sorry! This is from the relaxed memory address alignment changes I've
been making to reduce the need for bounce buffers.

> @@ -1949,6 +1949,7 @@ static int null_add_dev(struct nullb_device *dev)
>  		.logical_block_size	= dev->blocksize,
>  		.physical_block_size	= dev->blocksize,
>  		.max_hw_sectors		= dev->max_sectors,
> +		.dma_alignment		= dev->blocksize - 1,
>  	};

It looks like null_blk only needs (SECTOR_SIZE - 1). All the data copies
work in sector_t units and SECTOR_SIZE granularity, so does dma
alignment really need to match the blocksize if it's, for example, 4k?
And if not, since null_blk didn't set dma_alignment before, it should
have been defaulting to 511 already.

  parent reply	other threads:[~2025-10-29 14:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 13:39 [PATCH] null_blk: set dma alignment to logical block size Hans Holmberg
2025-10-29 13:51 ` Christoph Hellwig
2025-10-29 13:51   ` Christoph Hellwig
2025-10-29 14:12 ` Keith Busch [this message]
2025-10-29 15:32   ` Hans Holmberg
2025-10-29 16:01     ` Hans Holmberg
2025-10-29 16:06     ` Keith Busch
2025-10-29 16:15       ` Keith Busch
2025-10-30 12:32         ` Hans Holmberg
2025-10-31  9:00 ` Christoph Hellwig

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=aQIgvwec4Ol7ed8K@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=hans.holmberg@wdc.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=shinichiro.kawasaki@wdc.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.