Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2377148pxk; Sun, 20 Sep 2020 01:30:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJmNAXVjvjWXjwQDjJPGlNolZLbyLOxXfDLFGdgwtB3m8Vx1kgE60ONZqhKn2lrXrTztk5 X-Received: by 2002:a17:906:4c81:: with SMTP id q1mr43168888eju.72.1600590604578; Sun, 20 Sep 2020 01:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600590604; cv=none; d=google.com; s=arc-20160816; b=DNm6XCw7Y8ICNZeA1rYljKJQw1iAiNqqJb9iET4oqrSS+0HeRVN2zTf/6auUcre3zU 8bAYJBE0MCtY0IAwsRFdmKVYWqeHtcZqWkjvHL521ucPEN7T70mzr7y8Oy/Wk6RPTK1t 4NYIzhLj+Nuhu/lNOydme1u7Ajx+EtCL5WC3hhR8l1NJDfXzNfstI+IOqS5Tbet35gf6 FVMPl0mVP2LG5TjIqwZoPt3IPkGrJ3QGd64dXFIm9SzdViYV3GTE0zp7VJA1une+NGa5 vJk85QVuWXUtO3hZ3STzopFZEYTRzcy+NdXL1zON+WRZhKdv4YdJUbp2C8X4Xv7vMhfw 2BiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=W6tGRigsE1yyB2bweijCTmTB6SGWUAuSBU+d+3mWPy0=; b=GeUrIr6FKy3QyHoCnOmYfb6Y77yrGwG9m9532AEbzjZ2pU6LH7eDsY8XlNbbltN60j 3FeZ32OSLbpjkHOIDQop6AH8OcocoV0hzZRAeIyV0FLzfibqv/MMCy5HRQslriQaHY0L SDS8o8hamQ9+/tO4JawzPVtOrzyOqb86jqHMYeWjHvmLOuAzZj02uWoVPwSnerp6XU5G GDapcqQl+tSnvyFcYzDPa66kYAJvJ0fB4XnQa84q8+o/MEip7lhbnepIJrrhtd/ILtVW izGBcBtfAskwVVLRGR69upcSOMmhuJNfp19owI8Zd0naVHlxfss0VcrNrJnicM+06Bz3 RDnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 25si6095840ejv.234.2020.09.20.01.29.41; Sun, 20 Sep 2020 01:30:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726311AbgITI2O convert rfc822-to-8bit (ORCPT + 99 others); Sun, 20 Sep 2020 04:28:14 -0400 Received: from smtp.h3c.com ([60.191.123.50]:7649 "EHLO h3cspam02-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726216AbgITI2O (ORCPT ); Sun, 20 Sep 2020 04:28:14 -0400 Received: from DAG2EX07-IDC.srv.huawei-3com.com ([10.8.0.70]) by h3cspam02-ex.h3c.com with ESMTPS id 08K8QiiG013053 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 20 Sep 2020 16:26:44 +0800 (GMT-8) (envelope-from tian.xianting@h3c.com) Received: from DAG2EX03-BASE.srv.huawei-3com.com (10.8.0.66) by DAG2EX07-IDC.srv.huawei-3com.com (10.8.0.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 20 Sep 2020 16:26:47 +0800 Received: from DAG2EX03-BASE.srv.huawei-3com.com ([fe80::5d18:e01c:bbbd:c074]) by DAG2EX03-BASE.srv.huawei-3com.com ([fe80::5d18:e01c:bbbd:c074%7]) with mapi id 15.01.1713.004; Sun, 20 Sep 2020 16:26:46 +0800 From: Tianxianting To: Keith Busch CC: "axboe@fb.com" , "hch@lst.de" , "sagi@grimberg.me" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe() Thread-Topic: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe() Thread-Index: AQHWjamkvjMzTC+ou0aptn5bKR4hY6luQCAAgAEKLTCAAd/R8A== Date: Sun, 20 Sep 2020 08:26:46 +0000 Message-ID: <4e8aec9ebe8a4b8792632e71cb4a0e65@h3c.com> References: <20200918104420.30219-1-tian.xianting@h3c.com> <20200918192034.GA4030837@dhcp-10-100-145-180.wdl.wdc.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.141.128] x-sender-location: DAG2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 08K8QiiG013053 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I test and get the init flow of nvme admin queue and io queue in kernel 5.6, Currently, the code use nvmeq->q_depth as the upper limit for tag in nvme_handle_cqe(), according to below init flow, we already have the race currently. Admin queue init flow: 1, set nvmeq->q_depth 32 for admin queue; 2, register irq handler(nvme_irq) for admin queue 0; 3, set admin_tagset.queue_depth to 30 and alloc rqs; 4, nvme irq happen on admin queue; IO queue init flow: 1, set nvmeq->q_depth 1024 for io queue 1~16; 2, register irq handler(nvme_irq) for io queue 1~16; 3, set tagset.queue_depth to 1023 and alloc rqs; 4, nvme irq happen on io queue; So we have two issues need to fix: 1, register interrupt handler(nvme_irq) after tagset init(step 3 above) done to avoid a race; 2, use correct upper limit(queue_depth in tagset) for tag in nvme_handle_cqe(), which is the issue that will be solved in this patch I submitted. Is it right? Thanks a lot. -----Original Message----- From: tianxianting (RD) Sent: Saturday, September 19, 2020 11:15 AM To: 'Keith Busch' Cc: axboe@fb.com; hch@lst.de; sagi@grimberg.me; linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe() Hi Keith, Thanks a lot for your comments, I will try to figure out a safe fix for this issue, then for you review:) -----Original Message----- From: Keith Busch [mailto:kbusch@kernel.org] Sent: Saturday, September 19, 2020 3:21 AM To: tianxianting (RD) Cc: axboe@fb.com; hch@lst.de; sagi@grimberg.me; linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe() On Fri, Sep 18, 2020 at 06:44:20PM +0800, Xianting Tian wrote: > @@ -940,7 +940,9 @@ static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx) > struct nvme_completion *cqe = &nvmeq->cqes[idx]; > struct request *req; > > - if (unlikely(cqe->command_id >= nvmeq->q_depth)) { > + if (unlikely(cqe->command_id >= > + nvmeq->qid ? nvmeq->dev->tagset.queue_depth : > + nvmeq->dev->admin_tagset.queue_depth)) { Both of these values are set before blk_mq_alloc_tag_set(), so you still have a race. The interrupt handler probably just shouldn't be registered with the queue before the tagset is initialized since there can't be any work for the handler to do before that happens anyway. The controller is definitely broken, though, and will lead to unavoidable corruption if it's really behaving this way.