Patch "block: sed-opal: kmalloc the cmd/resp buffers" has been added to the 4.14-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    block: sed-opal: kmalloc the cmd/resp buffers

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     block-sed-opal-kmalloc-the-cmd-resp-buffers.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 52f5eac30090bd0662cf7276fe10ec2ff2019890
Author: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
Date:   Mon Nov 7 23:39:44 2022 +0300

    block: sed-opal: kmalloc the cmd/resp buffers
    
    [ Upstream commit f829230dd51974c1f4478900ed30bb77ba530b40 ]
    
    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.
    
    Note this fix was inspired by the commit c94b7f9bab22 ("nvme-hwmon:
    kmalloc the NVME SMART log buffer").
    
    [1] Documentation/core-api/dma-api.rst
    [2] Documentation/core-api/dma-api-howto.rst
    
    Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
    Signed-off-by: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Link: https://lore.kernel.org/r/20221107203944.31686-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx
    Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/block/sed-opal.c b/block/sed-opal.c
index c64011cda9fc..ae902077cd9d 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -94,8 +94,8 @@ struct opal_dev {
 	u64 lowest_lba;
 
 	size_t pos;
-	u8 cmd[IO_BUFFER_LENGTH];
-	u8 resp[IO_BUFFER_LENGTH];
+	u8 *cmd;
+	u8 *resp;
 
 	struct parsed_resp parsed;
 	size_t prev_d_len;
@@ -2011,6 +2011,8 @@ void free_opal_dev(struct opal_dev *dev)
 	if (!dev)
 		return;
 	clean_opal_dev(dev);
+	kfree(dev->resp);
+	kfree(dev->cmd);
 	kfree(dev);
 }
 EXPORT_SYMBOL(free_opal_dev);
@@ -2023,16 +2025,38 @@ struct opal_dev *init_opal_dev(void *data, sec_send_recv *send_recv)
 	if (!dev)
 		return NULL;
 
+	/*
+	 * Presumably DMA-able buffers must be cache-aligned. Kmalloc makes
+	 * sure the allocated buffer is DMA-safe in that regard.
+	 */
+	dev->cmd = kmalloc(IO_BUFFER_LENGTH, GFP_KERNEL);
+	if (!dev->cmd)
+		goto err_free_dev;
+
+	dev->resp = kmalloc(IO_BUFFER_LENGTH, GFP_KERNEL);
+	if (!dev->resp)
+		goto err_free_cmd;
+
 	INIT_LIST_HEAD(&dev->unlk_lst);
 	mutex_init(&dev->dev_lock);
 	dev->data = data;
 	dev->send_recv = send_recv;
 	if (check_opal_support(dev) != 0) {
 		pr_debug("Opal is not supported on this device\n");
-		kfree(dev);
-		return NULL;
+		goto err_free_resp;
 	}
 	return dev;
+
+err_free_resp:
+	kfree(dev->resp);
+
+err_free_cmd:
+	kfree(dev->cmd);
+
+err_free_dev:
+	kfree(dev);
+
+	return NULL;
 }
 EXPORT_SYMBOL(init_opal_dev);