[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <166792895795.7601.10122514732945288817.b4-ty@kernel.dk>
Date: Tue, 08 Nov 2022 10:35:57 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Sagi Grimberg <sagi@...mberg.me>,
Serge Semin <Sergey.Semin@...kalelectronics.ru>,
Scott Bauer <scott.bauer@...el.com>,
Jonathan Derrick <jonathan.derrick@...ux.dev>,
Keith Busch <kbusch@...nel.org>,
Rafael Antognolli <Rafael.Antognolli@...el.com>,
Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>
Cc: linux-block@...r.kernel.org,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
linux-nvme@...ts.infradead.org,
Serge Semin <fancer.lancer@...il.com>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] block: sed-opal: kmalloc the cmd/resp buffers
On Mon, 7 Nov 2022 23:39:44 +0300, 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 [2]. Seeing the
> opal_dev.{cmd,resp} buffers are implicitly used for DMAs in the NVME and
> SCSI/SD drivers in framework of the nvme_sec_submit() and sd_sec_submit()
> methods respectively they must be cacheline-aligned to prevent the denoted
> problem. One of the option to guarantee that is to kmalloc the buffers
> [2]. Let's explicitly allocate them then instead of embedding into the
> opal_dev structure instance.
>
> [...]
Applied, thanks!
[1/1] block: sed-opal: kmalloc the cmd/resp buffers
(no commit info)
Best regards,
--
Jens Axboe
Powered by blists - more mailing lists