From patchwork Mon Nov 7 20:39:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 16675 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2288155wru; Mon, 7 Nov 2022 12:52:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf5D/S+YX0zG6C7QxaEeL8b+5phrLfibhMlQlLKvLKe7zYjjMcuBGRIV14ZzcEKw2Zpp+co4 X-Received: by 2002:a17:907:7422:b0:7ae:7993:ae06 with SMTP id gj34-20020a170907742200b007ae7993ae06mr806366ejc.226.1667854363404; Mon, 07 Nov 2022 12:52:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667854363; cv=none; d=google.com; s=arc-20160816; b=GcNhAC0yLzemdswuaHBNU3d5QPgltKIShFgBRMJaZ+baZxLo/d0KRFAHsOC2mwXyK0 TFUuX74ot+QesMqRYHyx1ULCb9Dn8omb2JZXYGmZ6NSQDW/Plwra/csaC206JMJe3gwg 1TfSbvnl1GriEO7dHE8stkMFywAlNMoFQzL6PLeMo2MNaP4t6Uu4NkZ4md30OkT29XEo wi2SHbtR6oCJJUCzoQSUAHSNInGToqeELYT7kQWodwUykmjHCETdMnGoCunOjHlsoqnB ekWj4jJlJTFgsTbpxT6fxaoMVBZRFYso6Ym3x2XXoynImcQ/FpUOwjuZmWJcgRqYs/dY 43EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Mo1IoZxL2Rc3as4wkOOmjS2i89Ql8ugECSEPpbB7MWg=; b=aEC0Fyex4SyjBGV3IjnafxuFegZC9PDZ56+xFGT+HE2im5we1WlffA2pHAjwWT/6v5 AQpI19x66HZ1++WwrchiooiLLANJr0yVoRVFMWZYXCNirwUfLtpQfSA0uc96/YuqlRQZ c7trlF23uMTGc4Pm95JYZibxEoSym86zCvelx3WGKd385g5jXblr4Ywl0VGgTY+1AHXT kXHwa2cnyl7MsDoXx2ks7UOodothd0GFMr4jW2pYlTCutgVHEq006H965tth+BUYNzH3 LpZf77hGRrUEPyoZddZchC32oNFvQ4CDFjM5VNfJ89YmGXkRZwtljwO5cYsydwtZxGqj 9thw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baikalelectronics.ru header.s=post header.b=HSnlfG0Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=baikalelectronics.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j11-20020a05640211cb00b00461f5bb2b79si12697808edw.458.2022.11.07.12.52.19; Mon, 07 Nov 2022 12:52:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@baikalelectronics.ru header.s=post header.b=HSnlfG0Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=baikalelectronics.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231733AbiKGUqL (ORCPT + 99 others); Mon, 7 Nov 2022 15:46:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232832AbiKGUqK (ORCPT ); Mon, 7 Nov 2022 15:46:10 -0500 X-Greylist: delayed 367 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 07 Nov 2022 12:46:01 PST Received: from post.baikalelectronics.com (post.baikalelectronics.com [213.79.110.86]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8A69CDF29; Mon, 7 Nov 2022 12:46:01 -0800 (PST) Received: from post.baikalelectronics.com (localhost.localdomain [127.0.0.1]) by post.baikalelectronics.com (Proxmox) with ESMTP id 34930E0EAB; Mon, 7 Nov 2022 23:39:52 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= baikalelectronics.ru; h=cc:cc:content-transfer-encoding :content-type:content-type:date:from:from:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=post; bh=Mo1IoZxL2Rc3as4wkOOmjS2i89Ql8ugECSEPpbB7MWg=; b=HSnlfG0Qw9cV EUSsAE5gB5l5RsG7gI/yi6CDe4s5N3vm3ieRL+4mVVTCib1v3Qe8hMYO5JyK1oeM DkkeZ/pjHPRUfJvXkjb7UBvC3jPj7K8/3mGzx0DIQTljXbUrP99lf9FO/oXxLaBO 3BSmLZTy88JYSOFHHyVMBYOXodfcWjI= Received: from mail.baikal.int (mail.baikal.int [192.168.51.25]) by post.baikalelectronics.com (Proxmox) with ESMTP id EE6EAE0E1D; Mon, 7 Nov 2022 23:39:51 +0300 (MSK) Received: from localhost (192.168.168.10) by mail (192.168.51.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 7 Nov 2022 23:39:51 +0300 From: Serge Semin To: Jens Axboe , Jens Axboe , Keith Busch , Christoph Hellwig , Jonathan Derrick , Sagi Grimberg , Scott Bauer , Rafael Antognolli CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , , , Subject: [PATCH v3] block: sed-opal: kmalloc the cmd/resp buffers Date: Mon, 7 Nov 2022 23:39:44 +0300 Message-ID: <20221107203944.31686-1-Sergey.Semin@baikalelectronics.ru> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20220929224648.8997-4-Sergey.Semin@baikalelectronics.ru> References: <20220929224648.8997-4-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 X-Originating-IP: [192.168.168.10] X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748872057033339540?= X-GMAIL-MSGID: =?utf-8?q?1748872057033339540?= 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 Reviewed-by: Christoph Hellwig --- Folks the NVME-part of the patchset has already been merged in Link: https://lore.kernel.org/linux-nvme/20220929224648.8997-1-Sergey.Semin@baikalelectronics.ru/ This modification is only leftover of the original series. So I've resent it as a separate patch. Link: https://lore.kernel.org/linux-nvme/20220929224648.8997-4-Sergey.Semin@baikalelectronics.ru/ Changelog v3: - Convert to allocating the cmd-/resp-buffers instead of cache-aligning them. (@Jonathan) - Resubmit the patch separately from the original series. - Rebase onto the kernel 6.1-rc3 --- block/sed-opal.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/block/sed-opal.c b/block/sed-opal.c index 2c5327a0543a..9bdb833e5817 100644 --- a/block/sed-opal.c +++ b/block/sed-opal.c @@ -87,8 +87,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; @@ -2175,6 +2175,8 @@ void free_opal_dev(struct opal_dev *dev) return; clean_opal_dev(dev); + kfree(dev->resp); + kfree(dev->cmd); kfree(dev); } EXPORT_SYMBOL(free_opal_dev); @@ -2187,6 +2189,18 @@ 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->flags = 0; @@ -2194,11 +2208,21 @@ struct opal_dev *init_opal_dev(void *data, sec_send_recv *send_recv) 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);