Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: Pass (protection.outlook.com: domain of mellanox.com designates
 193.47.165.251 as permitted sender) receiver=protection.outlook.com;
 client-ip=193.47.165.251; helo=mtlcas13.mtl.com;
Subject: Re: [PATCH] nvme-rdma: Avoid double freeing of async event data
To:     Prabhath Sajeepa <psajeepa@purestorage.com>, <kbusch@kernel.org>,
        <axboe@fb.com>, <hch@lst.de>, <sagi@grimberg.me>,
        <linux-nvme@lists.infradead.org>, <linux-kernel@vger.kernel.org>
CC:     <roland@purestorage.com>
References: <1583788073-39681-1-git-send-email-psajeepa@purestorage.com>
From:   Max Gurtovoy <maxg@mellanox.com>
Message-ID: <ad4a9a41-00d7-49b1-c5f0-db58a824e6a0@mellanox.com>
Date:   Mon, 9 Mar 2020 23:53:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <1583788073-39681-1-git-send-email-psajeepa@purestorage.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2020 21:54:17.1711
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9dd2682a-5999-47d1-dd35-08d7c4746a4f
X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a652971c-7d2e-4d9b-a6a4-d149256f461b;Ip=[193.47.165.251];Helo=[mtlcas13.mtl.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB6576
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 3/9/2020 11:07 PM, Prabhath Sajeepa wrote:
> The timeout of identify cmd, which is invoked as part of admin queue
> creation, can result in freeing of async event data both in
> nvme_rdma_timeout handler and error handling path of
> nvme_rdma_configure_admin queue thus causing NULL pointer reference.
> Call Trace:
>   ? nvme_rdma_setup_ctrl+0x223/0x800 [nvme_rdma]
>   nvme_rdma_create_ctrl+0x2ba/0x3f7 [nvme_rdma]
>   nvmf_dev_write+0xa54/0xcc6 [nvme_fabrics]
>   __vfs_write+0x1b/0x40
>   vfs_write+0xb2/0x1b0
>   ksys_write+0x61/0xd0
>   __x64_sys_write+0x1a/0x20
>   do_syscall_64+0x60/0x1e0
>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Prabhath Sajeepa <psajeepa@purestorage.com>
> Reviewed-by: Roland Dreier <roland@purestorage.com>
> ---
>   drivers/nvme/host/rdma.c | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
> index 3e85c5c..0fe08c4 100644
> --- a/drivers/nvme/host/rdma.c
> +++ b/drivers/nvme/host/rdma.c
> @@ -850,9 +850,11 @@ static int nvme_rdma_configure_admin_queue(struct nvme_rdma_ctrl *ctrl,
>   	if (new)
>   		blk_mq_free_tag_set(ctrl->ctrl.admin_tagset);
>   out_free_async_qe:
> -	nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe,
> -		sizeof(struct nvme_command), DMA_TO_DEVICE);
> -	ctrl->async_event_sqe.data = NULL;
> +	if (ctrl->async_event_sqe.data) {
> +		nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe,
> +			sizeof(struct nvme_command), DMA_TO_DEVICE);
> +		ctrl->async_event_sqe.data = NULL;
> +	}
>   out_free_queue:
>   	nvme_rdma_free_queue(&ctrl->queues[0]);
>   	return error;

Looks good,

Reviewed-by: Max Gurtovoy <maxg@mellanox.com>


We did the same fix in-house yesterday and planed to send it tomorrow :)