From patchwork Thu Sep 29 22:46:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12996077 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 58396C433FE for ; Fri, 30 Sep 2022 23:24:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232274AbiI3XYU (ORCPT ); Fri, 30 Sep 2022 19:24:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232169AbiI3XYS (ORCPT ); Fri, 30 Sep 2022 19:24:18 -0400 Received: from post.baikalelectronics.com (post.baikalelectronics.com [213.79.110.86]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 73F3E138F28; Fri, 30 Sep 2022 16:24:12 -0700 (PDT) Received: from post.baikalelectronics.com (localhost.localdomain [127.0.0.1]) by post.baikalelectronics.com (Proxmox) with ESMTP id 07C17E0EB3; Fri, 30 Sep 2022 01:46:55 +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=Vx5QSi8OG8I5TDDjDN/aJB31I8qaTz0i56lsAmojCc0=; b=oC95j9nfLRMq 6QQ26lh7oDVyH8p15LwfloY4UKNJWrwMY695jLiYtQT2qM9iAsm9PrC1Ld4v/70b bX96x+LTbE7c8ndZqS746wS5dzopkTolZj4/6owZasYtcBJn6oQJGtFfSRZvWlQW B06YUq+/qMhhLRRQh8G1ghmVqovzU7w= Received: from mail.baikal.int (mail.baikal.int [192.168.51.25]) by post.baikalelectronics.com (Proxmox) with ESMTP id ECC23E0E6B; Fri, 30 Sep 2022 01:46:54 +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; Fri, 30 Sep 2022 01:46:55 +0300 From: Serge Semin To: Jens Axboe , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Thomas Bogendoerfer , , , Subject: [PATCH v2 1/3] nvme-hwmon: Return error on kzalloc failure Date: Fri, 30 Sep 2022 01:46:46 +0300 Message-ID: <20220929224648.8997-2-Sergey.Semin@baikalelectronics.ru> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220929224648.8997-1-Sergey.Semin@baikalelectronics.ru> References: <20220929224648.8997-1-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) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Inability to allocate a buffer is a critical error which shouldn't be tolerated since most likely the rest of the driver won't work correctly. Thus instead of returning the zero status let's return the -ENOMEM error if the nvme_hwmon_data structure instance couldn't be created. Signed-off-by: Serge Semin --- Changelog v2: - New patch --- drivers/nvme/host/hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c index 0a586d712920..1afb24a64145 100644 --- a/drivers/nvme/host/hwmon.c +++ b/drivers/nvme/host/hwmon.c @@ -230,7 +230,7 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl) data = kzalloc(sizeof(*data), GFP_KERNEL); if (!data) - return 0; + return -ENOMEM; data->ctrl = ctrl; mutex_init(&data->read_lock); From patchwork Thu Sep 29 22:46:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12994727 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 D5A20C433F5 for ; Thu, 29 Sep 2022 23:04:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229489AbiI2XES (ORCPT ); Thu, 29 Sep 2022 19:04:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbiI2XER (ORCPT ); Thu, 29 Sep 2022 19:04:17 -0400 X-Greylist: delayed 602 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 29 Sep 2022 16:04:09 PDT Received: from post.baikalelectronics.com (post.baikalelectronics.com [213.79.110.86]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 69656125799; Thu, 29 Sep 2022 16:04:09 -0700 (PDT) Received: from post.baikalelectronics.com (localhost.localdomain [127.0.0.1]) by post.baikalelectronics.com (Proxmox) with ESMTP id B6FBEE0EB4; Fri, 30 Sep 2022 01:46:55 +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=UkQr9fjSZTvQkPs/TdOJJ7ucByrB+5O3OiT3zCPhxos=; b=daxnT/Wt2lRx LdfDcr8bocUrY/As/wrQG39sxic/sfkWdshgyzrgtjf9QJMcAo5I1pVo3qL7gvqQ RRckRfjNCmcMye6Mw4idHhU/+pdesabAan7qsgh3EazGyxT0eg9Vc+vw50M6J80Y EfH4/AnYtxYfqOIIK/Nu+Z3QQWvmKn8= Received: from mail.baikal.int (mail.baikal.int [192.168.51.25]) by post.baikalelectronics.com (Proxmox) with ESMTP id A8DEBE0E6B; Fri, 30 Sep 2022 01:46:55 +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; Fri, 30 Sep 2022 01:46:56 +0300 From: Serge Semin To: 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 v2 2/3] nvme-hwmon: Kmalloc the NVME SMART log buffer Date: Fri, 30 Sep 2022 01:46:47 +0300 Message-ID: <20220929224648.8997-3-Sergey.Semin@baikalelectronics.ru> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220929224648.8997-1-Sergey.Semin@baikalelectronics.ru> References: <20220929224648.8997-1-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) 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. One of the option to guarantee that is to kmalloc the DMA-buffer [1]. Seeing the rest of the NVME core driver prefer that method it has been chosen to fix this problem too. Note 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-howto.rst Fixes: 400b6a7b13a3 ("nvme: Add hardware monitoring support") Signed-off-by: Serge Semin --- 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). I am still not fully sure regarding the buffers coming from user-space though, but AFAICS based on our DMA-buffers-alignment sanity check procedure they haven't been detected as cache-unaligned so far. Changelog v2: - Convert to allocating the nvme_smart_log structure instance instead of cache-aligning it. (@Christoph) --- drivers/nvme/host/hwmon.c | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c index 1afb24a64145..654309767e76 100644 --- a/drivers/nvme/host/hwmon.c +++ b/drivers/nvme/host/hwmon.c @@ -12,7 +12,7 @@ struct nvme_hwmon_data { struct nvme_ctrl *ctrl; - struct nvme_smart_log log; + struct nvme_smart_log *log; struct mutex read_lock; }; @@ -60,14 +60,14 @@ static int nvme_set_temp_thresh(struct nvme_ctrl *ctrl, int sensor, bool under, static int nvme_hwmon_get_smart_log(struct nvme_hwmon_data *data) { return nvme_get_log(data->ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0, - NVME_CSI_NVM, &data->log, sizeof(data->log), 0); + NVME_CSI_NVM, data->log, sizeof(*data->log), 0); } static int nvme_hwmon_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel, long *val) { struct nvme_hwmon_data *data = dev_get_drvdata(dev); - struct nvme_smart_log *log = &data->log; + struct nvme_smart_log *log = data->log; int temp; int err; @@ -163,7 +163,7 @@ static umode_t nvme_hwmon_is_visible(const void *_data, case hwmon_temp_max: case hwmon_temp_min: if ((!channel && data->ctrl->wctemp) || - (channel && data->log.temp_sensor[channel - 1])) { + (channel && data->log->temp_sensor[channel - 1])) { if (data->ctrl->quirks & NVME_QUIRK_NO_TEMP_THRESH_CHANGE) return 0444; @@ -176,7 +176,7 @@ static umode_t nvme_hwmon_is_visible(const void *_data, break; case hwmon_temp_input: case hwmon_temp_label: - if (!channel || data->log.temp_sensor[channel - 1]) + if (!channel || data->log->temp_sensor[channel - 1]) return 0444; break; default: @@ -232,14 +232,19 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl) if (!data) return -ENOMEM; + data->log = kzalloc(sizeof(*data->log), GFP_KERNEL); + if (!data->log) { + err = -ENOMEM; + goto err_free_data; + } + data->ctrl = ctrl; mutex_init(&data->read_lock); err = nvme_hwmon_get_smart_log(data); if (err) { dev_warn(dev, "Failed to read smart log (error %d)\n", err); - kfree(data); - return err; + goto err_free_log; } hwmon = hwmon_device_register_with_info(dev, "nvme", @@ -247,11 +252,19 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl) NULL); if (IS_ERR(hwmon)) { dev_warn(dev, "Failed to instantiate hwmon device\n"); - kfree(data); - return PTR_ERR(hwmon); + err = PTR_ERR(hwmon); + goto err_free_log; } ctrl->hwmon_device = hwmon; return 0; + +err_free_log: + kfree(data->log); + +err_free_data: + kfree(data); + + return err; } void nvme_hwmon_exit(struct nvme_ctrl *ctrl) @@ -262,6 +275,7 @@ void nvme_hwmon_exit(struct nvme_ctrl *ctrl) hwmon_device_unregister(ctrl->hwmon_device); ctrl->hwmon_device = NULL; + kfree(data->log); kfree(data); } } From patchwork Thu Sep 29 22:46:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12996078 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 A8332C4321E for ; Fri, 30 Sep 2022 23:24:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232296AbiI3XYW (ORCPT ); Fri, 30 Sep 2022 19:24:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232113AbiI3XYS (ORCPT ); Fri, 30 Sep 2022 19:24:18 -0400 Received: from post.baikalelectronics.com (post.baikalelectronics.com [213.79.110.86]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7411715A700; Fri, 30 Sep 2022 16:24:12 -0700 (PDT) Received: from post.baikalelectronics.com (localhost.localdomain [127.0.0.1]) by post.baikalelectronics.com (Proxmox) with ESMTP id 63B39E0EB5; Fri, 30 Sep 2022 01:46:56 +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=wuhxWCVeXVlJVS/RfP/AZNvPaB2WtIt+hlprDEaQew8=; b=tp0ozYnJRVZb 3eOjGM6LN8TCwm25Q+QFgtbgIAcq6fonGNSvoBN/ax9zXSP9KuFKSHRRJhS6lHBY Hp9D7/pv0NAdDxGCXECCbCHCzU+5HbRntTZwP29CWCnCUKnIXExi1hNXj9wDXbL1 rI4PnhJFrDkO3LC4RvuG+ywABgJbY1w= Received: from mail.baikal.int (mail.baikal.int [192.168.51.25]) by post.baikalelectronics.com (Proxmox) with ESMTP id 56706E0E6B; Fri, 30 Sep 2022 01:46:56 +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; Fri, 30 Sep 2022 01:46:57 +0300 From: Serge Semin To: Jens Axboe , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Jonathan Derrick , Revanth Rajashekar , Rafael Antognolli , Scott Bauer CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Thomas Bogendoerfer , , , Subject: [PATCH v2 3/3] block: sed-opal: Cache-line-align the cmd/resp buffers Date: Fri, 30 Sep 2022 01:46:48 +0300 Message-ID: <20220929224648.8997-4-Sergey.Semin@baikalelectronics.ru> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220929224648.8997-1-Sergey.Semin@baikalelectronics.ru> References: <20220929224648.8997-1-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) 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;