From patchwork Fri Sep 9 19:19:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12972067 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8808ECAAA1 for ; Fri, 9 Sep 2022 19:19:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229651AbiIITTi (ORCPT ); Fri, 9 Sep 2022 15:19:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbiIITTh (ORCPT ); Fri, 9 Sep 2022 15:19:37 -0400 Received: from mail.baikalelectronics.com (mail.baikalelectronics.com [87.245.175.230]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AB03F12AAF; Fri, 9 Sep 2022 12:19:34 -0700 (PDT) Received: from mail (mail.baikal.int [192.168.51.25]) by mail.baikalelectronics.com (Postfix) with ESMTP id E8885DBA; Fri, 9 Sep 2022 22:23:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.baikalelectronics.com E8885DBA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baikalelectronics.ru; s=mail; t=1662751391; bh=g/qnbR3kmCe/hsDgvp6zCp5qkLBtvy6bgBjvx6x6e8w=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=YES6vKyJfvMMdrO20kNxAanHBoFyOZ10pFXxE7G1x4aD++ilUms+nwqjVLYPDYEDD 7KE5Frp3PJ6w++pm8zZ0XWDuVTnhPWxcgWSNMuspnYaVeh+L5e5CPxHUDOR5k5Fo88 C90Jhz+tvIVTQlW1sFqCSYEiGhodiDd9T0xPo0M8= Received: from localhost (192.168.168.10) by mail (192.168.51.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Sep 2022 22:19:20 +0300 From: Serge Semin To: Jonathan Derrick , Revanth Rajashekar , Jens Axboe , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Guenter Roeck CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Thomas Bogendoerfer , , , Subject: [PATCH 1/2] nvme-hwmon: Cache-line-align the NVME SMART log-buffer Date: Fri, 9 Sep 2022 22:19:15 +0300 Message-ID: <20220909191916.16013-2-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20220909191916.16013-1-Sergey.Semin@baikalelectronics.ru> References: <20220909191916.16013-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Recent commit 52fde2c07da6 ("nvme: set dma alignment to dword") has caused a regression on our platform. It turned out that the nvme_get_log() method invocation caused the nvme_hwmon_data structure instance corruption. In particular the nvme_hwmon_data.ctrl pointer was overwritten either with zeros or with garbage. After some researches we discovered that the problem happened even before the actual NVME DMA execution, but during the buffer mapping. Since our platform was DMA-noncoherent the mapping implied the cache-lines invalidations or write-backs depending on the DMA-direction parameter. In case of the NVME SMART log getting the DMA was performed from-device-to-memory, thus the cache-invalidation was activated during the buffer mapping. Since the log-buffer wasn't cache-line aligned the cache-invalidation caused the neighbour data discard. The neighbouring data turned to be the data surrounding the buffer in the framework of the nvme_hwmon_data structure. In order to fix that we need to make sure that the whole log-buffer is defined within the cache-line-aligned memory region so the cache-invalidation procedure wouldn't involve the adjacent data. By doing so we not only get rid from the denoted problem but also fulfill the requirement explicitly described in [1]. After a deeper researches we found out that the denoted commit wasn't a root cause of the problem. It just revealed the invalidity by activating the DMA-based NVME SMART log getting performed in the framework of the NVME hwmon driver. The problem was here since the initial commit of the driver. [1] Documentation/core-api/dma-api.rst Fixes: 400b6a7b13a3 ("nvme: Add hardware monitoring support") Signed-off-by: Serge Semin Reviewed-by: Keith Busch Reviewed-by: Guenter Roeck --- 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). --- 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; struct mutex read_lock; }; From patchwork Fri Sep 9 19:19:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12972069 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30585ECAAD5 for ; Fri, 9 Sep 2022 19:19:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230254AbiIITTs (ORCPT ); Fri, 9 Sep 2022 15:19:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230150AbiIITTm (ORCPT ); Fri, 9 Sep 2022 15:19:42 -0400 Received: from mail.baikalelectronics.com (mail.baikalelectronics.com [87.245.175.230]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 75D0D2A42B; Fri, 9 Sep 2022 12:19:40 -0700 (PDT) Received: from mail (mail.baikal.int [192.168.51.25]) by mail.baikalelectronics.com (Postfix) with ESMTP id 3D9A2DBB; Fri, 9 Sep 2022 22:23:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.baikalelectronics.com 3D9A2DBB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baikalelectronics.ru; s=mail; t=1662751391; bh=k04JpT/Stk+B/Zc/3fGfPQL4s7cQC+RHy2d6ex7akDU=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=O4gzvBhHAEGnSNm1f2kkZ6UEROqGLedhiAQeKD2i2IPo4oHcWkAVshH5GltVljce7 PudFDDrmSGjqMFYD5fBijw38Upb/+TrRtwNPdD3nUpAlpRee9joZr4YINs3kF+CCCd YSIPFPKpAb7az2+yxffnEs0ilQlNlpMIxlPTfu5g= Received: from localhost (192.168.168.10) by mail (192.168.51.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Sep 2022 22:19:21 +0300 From: Serge Semin To: Jonathan Derrick , Revanth Rajashekar , Jens Axboe , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Rafael Antognolli , Scott Bauer CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Thomas Bogendoerfer , , , Subject: [PATCH 2/2] block: sed-opal: Cache-line-align the cmd/resp buffers Date: Fri, 9 Sep 2022 22:19:16 +0300 Message-ID: <20220909191916.16013-3-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20220909191916.16013-1-Sergey.Semin@baikalelectronics.ru> References: <20220909191916.16013-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 --- 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; struct parsed_resp parsed; size_t prev_d_len;