Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp3732026rdh; Tue, 28 Nov 2023 02:14:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IE6C/QtTDoZuZPM43C4mbursjhHuVjQpCaOvM+1T82RQ77vDcODAkdOXDzoU5jxecc0RE+Q X-Received: by 2002:a05:6a00:10d2:b0:6cb:4bd5:a4c5 with SMTP id d18-20020a056a0010d200b006cb4bd5a4c5mr17928002pfu.9.1701166461328; Tue, 28 Nov 2023 02:14:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701166461; cv=none; d=google.com; s=arc-20160816; b=ob1FJqWLQykeq26TgmIUWjhqrzq7yxlbkTf4L24bV78nr21nO5EXd/qfn1OYSpi2ir CxAPkoRzUN6/1YbETg22R59nxgtpMLkzOePuLNYJnmq3Hf0XkbemKNSG4zyiACAacQHj 1p3U7Zr/Kzfynrc+oGoScJ/s/wDbqQl7kZM+Wb4efq3+7JcsnQxYei4Cz7m3sfnzfm5V 7wMuAvn/GZYK6iviNPgr+rVLgWoC7IkVmTqB88A8PWo9ttNn3/+0uL5Is0JLWqQjSivc 6QUoHydk3pze1fQgyZkijRygbanUzYsf1z+Ap30hPOS3MD8C28mKLrm0DyUTTUsv4yPr N6VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=+PyeWkhuJYg+ePFp+kSJvaI5luSTG8Uu2UJZLlj/UZo=; fh=RE1rn0GclFvccYLDhLPPKdXJUVtVHdooiyv8OuNC71o=; b=m33XJvdkDrWxH0BDqLFr/sm4q+eb5+B4etJCEyg7gh36MVG83+bKYf5m3vvbVUvKp4 phnEOrRftHKhM2A22UnhMiTXdJRU8S0ybyY5HjxjMzBpvECsl7/OI7hkj43DKP2BRAKQ iPAOHNQRCfi5xhJgbsxs6KSiGzMzTQWUqSB2EogbbAvBjNy8lUm/3CIh+ZIAw+S1TujP 2pE6/R1E3fY1drQqNeZIGngVwYPQByWA3CdgpCmSn7LmOFlz/ZluK0Go4zEX5f1htvak ILP00FOzPnMt6cMBQ7hQxuPmyt4pXm4t4Ky29EReiCqZG4KLAWzbT7s6el9p3fqGa9nN +wIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id z18-20020a056a001d9200b006cbf70da0bbsi10078185pfw.54.2023.11.28.02.14.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 02:14:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id AACFC81ADCEE; Tue, 28 Nov 2023 02:14:18 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234651AbjK1KOB (ORCPT + 99 others); Tue, 28 Nov 2023 05:14:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232873AbjK1KN7 (ORCPT ); Tue, 28 Nov 2023 05:13:59 -0500 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F4ADDE for ; Tue, 28 Nov 2023 02:14:05 -0800 (PST) Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-332eac4dec4so784465f8f.1 for ; Tue, 28 Nov 2023 02:14:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701166443; x=1701771243; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+PyeWkhuJYg+ePFp+kSJvaI5luSTG8Uu2UJZLlj/UZo=; b=fUee5sAhP5pSHGeIiOFKlKASNdkdG+h5VPDCiULGIhgGHPhRRQURh5W0VA2C/pvXYK YQe3rUZqXLQ6YFaH2WxYVVewfTrFoOna3SKl4i372DqOlXcauoExZ4vQDnhCfL2r1AQg Bmq6m5jBoIqWShGOS05tbtpo4J5+kGe/yl9cL/SlYN0H1XEy/n3t5SIn6L3PPcDqoIFp h3rHKgRgyc4N5v30Sk0Ak2mKJELWNCiG8mfIaAzlpu7CkDE6008ApZNCXvZeetNPuFbY uAgxisC5LBMtRPaYq/M3OWXidZGy2MYW5H2GHLceO2yn0X6GF9OKiYul5F0HBBl53Ejy 7XUQ== X-Gm-Message-State: AOJu0Yy90Lh2KTDSBsw7Js18Bafp2uPJ6Y1Bzkom0OUXNSHbsg9J5iPf b04ImoM774SQnkqc1EcyF6g= X-Received: by 2002:adf:e7cd:0:b0:333:7ad:58e7 with SMTP id e13-20020adfe7cd000000b0033307ad58e7mr2618743wrn.4.1701166443159; Tue, 28 Nov 2023 02:14:03 -0800 (PST) Received: from [192.168.64.177] (bzq-219-42-90.isdn.bezeqint.net. [62.219.42.90]) by smtp.gmail.com with ESMTPSA id a11-20020adff7cb000000b00332fda15056sm6524961wrq.110.2023.11.28.02.14.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Nov 2023 02:14:02 -0800 (PST) Message-ID: Date: Tue, 28 Nov 2023 12:13:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nvme: fix deadlock between reset and scan Content-Language: en-US To: yaoma , Keith Busch Cc: axboe@kernel.dk, hch@lst.de, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, kanie@linux.alibaba.com References: <1700737213-110685-1-git-send-email-yaoma@linux.alibaba.com> <65b0c372-b308-46dd-c2f2-a5ddb50adb10@linux.alibaba.com> From: Sagi Grimberg In-Reply-To: <65b0c372-b308-46dd-c2f2-a5ddb50adb10@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 28 Nov 2023 02:14:18 -0800 (PST) On 11/28/23 08:22, yaoma wrote: > Hi Keith Busch > > Thanks for your reply. > > The idea to avoid such a deadlock between nvme_reset and nvme_scan is to > ensure that no namespace can be added to ctrl->namespaces after > nvme_start_freeze has already been called. We can achieve this goal by > assessing the ctrl->state after we have already acquired the > ctrl->namespaces_rwsem lock, to decide whether to add the namespace to > the list or not. > 1. After we determine that ctrl->state is LIVE, it may be immediately > changed to another state. However, since we have already acquired the > lock, other tasks cannot access ctrl->namespace, so we can still safely > add the namespace to the list. After acquiring the lock, > nvme_start_freeze will freeze all ns->q in the list, including any newly > added namespaces. > 2. Before the completion of nvme_reset, ctrl->state will not be changed > to LIVE, so we will not add any more namespaces to the list. All ns->q > in the list is frozen, so nvme_wait_freeze can exit normally. I agree with the analysis, there is a hole between start_freeze and freeze_wait that a scan may add a ns to the ctrl ns list. However the fix should be to mark the ctrl with say NVME_CTRL_FROZEN flag set in nvme_freeze_start and cleared in nvme_unfreeze (similar to what we did with quiesce). Then the scan can check it before adding the new namespace (under the namespaces_rwsem).