On Fri, Sep 09, 2022 at 10:19:15PM +0300, Serge Semin wrote: > Recent commit 52fde2c07da6 ("nvme: set dma alignment to dword") has caused > > Folks, I've thoroughly studied the whole NVME subsystem looking for > similar problems. Turned out there is one more place which may cause the > same issue. It's connected with the opal_dev.{cmd,req} buffers passed to > the nvme_sec_submit() method. The rest of the buffers involved in the NVME > DMA are either allocated by kmalloc (must be cache-line-aligned by design) > or bounced-buffered if allocated on the stack (see the blk_rq_map_kern() > method implementation). What about user space addresses? We can map those with cacheline offsets. > --- > drivers/nvme/host/hwmon.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c > index 0a586d712920..94192ab7a02d 100644 > --- a/drivers/nvme/host/hwmon.c > +++ b/drivers/nvme/host/hwmon.c > @@ -10,9 +10,10 @@ > > #include "nvme.h" > > +/* DMA-noncoherent platforms require the cache-aligned buffers */ > struct nvme_hwmon_data { > + struct nvme_smart_log log ____cacheline_aligned; > struct nvme_ctrl *ctrl; > - struct nvme_smart_log log; So this by chance happened to work before 52fde2c07da6 because the field started at a 4-byte offset on your arch? The change looks good. Reviewed-by: Keith Busch <kbusch@xxxxxxxxxx>