Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp885662ybe; Wed, 4 Sep 2019 09:09:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzVw0SWP2T4Av8fhw0mTu922X3BZY5BweaByeseD/H8rlmv1aRNrUy4lxb3SmNomPUxpRy2 X-Received: by 2002:a62:2d3:: with SMTP id 202mr34335113pfc.141.1567613389397; Wed, 04 Sep 2019 09:09:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567613389; cv=none; d=google.com; s=arc-20160816; b=O3HXAcyLn/Aby40ukzclwTBDhuO1m532GNfd8Ty1NPFQjmJRShSr2aIrfvNhjyeog0 1ILDFV6hta24q2Iri2eLfRvPL0Sr3R1ea7j8dMZlk4ECL02AWhedqUI+8uLyX8j5Bf/G FLITWTBq55nzrUwJfXJI8iu9jtlt8uojceY/Xmg2J6m/M3PeHMg0OLXYVwbJh7TMRcjW OW4Z64ctYEHhGs0uI3rewt0mYn1vFI9CNSGd48yVXiZJIFxXN4d7Q/AnCI5FNQsTf2LS A1rtWQyDpyoEkH77zXpZPJpTwqdm29O+5k8p9c3FOuzO9fh5fOD0QObq4vxGLSCg7+J+ +eGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to; bh=8Ys48jpB9R0oM1wbqbZ2gD3Oycyqg42YqMYhEnvtGM8=; b=S0I/8COb/erZa3cpLZkijh8AnqsdUUJDBlap9SQNedQTUSxN0Pi0YdcbbV6raB9BQV PPK/dHU7yT+5ZTEHpI9HY0+fIy6DBPRT+zwPeev8640qGdg3k1BU0P3M1LE/Ah+v9Qk5 hsbVZUpMM4MP5GN+mZ2XHk9Ol2bVYHAuad6mtkz8tsU8iaUeSrB0Kd/TZyfw+eet7B2Z sNX2c50NOIHqEwFU6o1dvcgXdcsIQhvJDzWjdbgiH4eC+iQUedpWleHJhYYXCVdcDTKJ sqjiE7owTUy72Yo9Pg8PLkqhyCtcgt/gr5HdvD166pR9GUjvgaB+w7f6g7JbnS+Yayln qGDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r200si17128981pgr.518.2019.09.04.09.09.32; Wed, 04 Sep 2019 09:09:49 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733231AbfIDQH0 (ORCPT + 99 others); Wed, 4 Sep 2019 12:07:26 -0400 Received: from ale.deltatee.com ([207.54.116.67]:57316 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728878AbfIDQHU (ORCPT ); Wed, 4 Sep 2019 12:07:20 -0400 Received: from s0106ac1f6bb1ecac.cg.shawcable.net ([70.73.163.230] helo=[192.168.11.155]) by ale.deltatee.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i5XoS-0006yr-3P; Wed, 04 Sep 2019 10:07:17 -0600 To: Keith Busch , Christoph Hellwig Cc: Jens Axboe , Hannes Reinecke , Sagi Grimberg , "Martin K . Petersen" , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Keith Busch References: <20190831000139.7662-1-logang@deltatee.com> <20190831152910.GA29439@localhost.localdomain> <33af4d94-9f6d-9baa-01fa-0f75ccee263e@deltatee.com> <20190903164620.GA20847@localhost.localdomain> <20190904060558.GA10849@lst.de> <20190904144426.GB21302@localhost.localdomain> <20190904154215.GA20422@lst.de> <20190904155445.GD21302@localhost.localdomain> From: Logan Gunthorpe Message-ID: Date: Wed, 4 Sep 2019 10:07:12 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190904155445.GD21302@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 70.73.163.230 X-SA-Exim-Rcpt-To: keith.busch@intel.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, martin.petersen@oracle.com, sagi@grimberg.me, hare@suse.com, axboe@fb.com, hch@lst.de, kbusch@kernel.org X-SA-Exim-Mail-From: logang@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [PATCH] nvme-core: Fix subsystem instance mismatches X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-09-04 9:54 a.m., Keith Busch wrote: > On Wed, Sep 04, 2019 at 05:42:15PM +0200, Christoph Hellwig wrote: >> On Wed, Sep 04, 2019 at 08:44:27AM -0600, Keith Busch wrote: >>> Let me step through an example: >>> >>> Ctrl A gets instance 0. >>> >>> Its subsystem gets the same instance, and takes ref count on it: >>> all namespaces in this subsystem will use '0'. >>> >>> Ctrl B gets instance 1, and it's in the same subsystem as Ctrl A so >>> no new subsytem is allocated. >>> >>> Ctrl A is disconnected, dropping its ref on instance 0, but the >>> subsystem still has its refcount, making it unavailable. >>> >>> Ctrl A is reconnected, and allocates instance 2 because 0 is still in >>> use. >>> >>> Now all the namespaces in this subsystem are prefixed with nvme0, but no >>> controller exists with the same prefix. We still have inevitable naming >>> mismatch, right? >> >> I think th major confusion was that we can use the same handle for >> and unrelated subsystem vs controller, and that would avoid it. >> >> I don't see how we can avoid the controller is entirely different >> from namespace problem ever. Yes, I agree, we can't solve the mismatch problem in the general case: with sequences of hot plug events there will always be a case that mismatches. I just think we can do better in the simple common default case. > Can we just ensure there is never a matching controller then? This > patch will accomplish that and simpler than wrapping the instance in a > refcount'ed object: > > http://lists.infradead.org/pipermail/linux-nvme/2019-May/024142.html I don't really like that idea. It reduces the confusion caused by mismatching numbers, but causes the controller to never match the namespace, which is also confusing but in a different way. I like the nvme_instance idea. It's not going to be perfect but it has some nice properties: the subsystem will try to match the controller's instance whenever possible, but in cases where it doesn't, the instance number of the subsystem will never be the same as an existing controller. I'll see if I can work up a quick patch set and see what people think. Logan