All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Derrick <jonathan.derrick@linux.dev>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Jens Axboe <axboe@kernel.dk>, Keith Busch <kbusch@kernel.org>,
	Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
	Sagi Grimberg <sagi@grimberg.me>,
	Jonathan Derrick <jonathan.derrick@intel.com>,
	Revanth Rajashekar <revanth.rajashekar@intel.com>,
	Rafael Antognolli <Rafael.Antognolli@intel.com>,
	Scott Bauer <scott.bauer@intel.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] block: sed-opal: Cache-line-align the cmd/resp buffers
Date: Mon, 3 Oct 2022 12:24:08 -0600	[thread overview]
Message-ID: <cce74aec-61b1-d5eb-1b62-746e45ebfe69@linux.dev> (raw)
In-Reply-To: <20220929224648.8997-4-Sergey.Semin@baikalelectronics.ru>

Hi

On 9/29/2022 4:46 PM, Serge Semin wrote:
> In accordance with [1] the DMA-able memory buffers must be
> cacheline-aligned otherwise the cache writing-back and invalidation
> performed during the mapping may cause the adjacent data being lost. It's
> specifically required for the DMA-noncoherent platforms. Seeing the
> opal_dev.{cmd,resp} buffers are used for DMAs in the NVME and SCSI/SD
> drivers in framework of the nvme_sec_submit() and sd_sec_submit() methods
> respectively we must make sure the passed buffers are cacheline-aligned to
> prevent the denoted problem.
> 
> [1] Documentation/core-api/dma-api.rst
> 
> Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   block/sed-opal.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/block/sed-opal.c b/block/sed-opal.c
> index 9700197000f2..222acbd1f03a 100644
> --- a/block/sed-opal.c
> +++ b/block/sed-opal.c
> @@ -73,6 +73,7 @@ struct parsed_resp {
>   	struct opal_resp_tok toks[MAX_TOKS];
>   };
>   
> +/* Presumably DMA-able buffers must be cache-aligned */
>   struct opal_dev {
>   	bool supported;
>   	bool mbr_enabled;
> @@ -88,8 +89,8 @@ struct opal_dev {
>   	u64 lowest_lba;
>   
>   	size_t pos;
> -	u8 cmd[IO_BUFFER_LENGTH];
> -	u8 resp[IO_BUFFER_LENGTH];
> +	u8 cmd[IO_BUFFER_LENGTH] ____cacheline_aligned;
> +	u8 resp[IO_BUFFER_LENGTH] ____cacheline_aligned;
I'm with Christoph on this one.
When I see ____cacheline_aligned, I assume its for performance reasons, 
not to work around a DMA limitation. Can we instead kmalloc (which 
provides alignment) these buffers to make it more clear? May want to add 
that same comment pointing out some architectures require these dma 
targets to be cache aligned.


>   
>   	struct parsed_resp parsed;
>   	size_t prev_d_len;

  reply	other threads:[~2022-10-03 18:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 22:46 [PATCH v2 0/3] block/nvme: Fix DMA-noncoherent platforms support Serge Semin
2022-09-29 22:46 ` [PATCH v2 1/3] nvme-hwmon: Return error on kzalloc failure Serge Semin
2022-09-29 23:53   ` Keith Busch
2022-09-30  9:52     ` Serge Semin
2022-09-30 14:57       ` Keith Busch
2022-10-04 14:50         ` Serge Semin
2022-10-04 17:33           ` Keith Busch
2022-10-07 10:01             ` Serge Semin
2022-09-29 22:46 ` [PATCH v2 2/3] nvme-hwmon: Kmalloc the NVME SMART log buffer Serge Semin
2022-10-17  7:18   ` Christoph Hellwig
2022-10-17 16:16     ` Serge Semin
2022-10-18 14:49       ` Christoph Hellwig
2022-09-29 22:46 ` [PATCH v2 3/3] block: sed-opal: Cache-line-align the cmd/resp buffers Serge Semin
2022-10-03 18:24   ` Jonathan Derrick [this message]
2022-10-04 15:32     ` Serge Semin
2022-11-07 20:39   ` [PATCH v3] block: sed-opal: kmalloc " Serge Semin
2022-11-08  6:22     ` Christoph Hellwig
2022-11-08 17:35     ` Jens Axboe

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=cce74aec-61b1-d5eb-1b62-746e45ebfe69@linux.dev \
    --to=jonathan.derrick@linux.dev \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Rafael.Antognolli@intel.com \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=fancer.lancer@gmail.com \
    --cc=hch@lst.de \
    --cc=jonathan.derrick@intel.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=revanth.rajashekar@intel.com \
    --cc=sagi@grimberg.me \
    --cc=scott.bauer@intel.com \
    --cc=tsbogend@alpha.franken.de \
    /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.