From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 035F1C433FF for ; Wed, 14 Aug 2019 16:08:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C9FEC2083B for ; Wed, 14 Aug 2019 16:08:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565798936; bh=bkucVjBQNTitZv09teJK5LdTp1SSWMyjRNUIpSPYc0I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=dt73WuwVQrgvmATER3X+dGk58di3xGyQY5/tXPYqncRLWsr91dPy/NXGqyw4Wc9Bv /IhgItizgmgBwSuVup2zXyQJpiFYAlHGbPJmepN5ockhEzcizYPD6NXvAR/6FSqmiO WIBlQKefeUz8+QaYH1UVNlk1OqHTyMeQ/tC+OYD0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726585AbfHNQI4 (ORCPT ); Wed, 14 Aug 2019 12:08:56 -0400 Received: from mga05.intel.com ([192.55.52.43]:17591 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726126AbfHNQI4 (ORCPT ); Wed, 14 Aug 2019 12:08:56 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2019 09:08:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,385,1559545200"; d="scan'208";a="179100197" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga003.jf.intel.com with ESMTP; 14 Aug 2019 09:08:54 -0700 Date: Wed, 14 Aug 2019 10:06:41 -0600 From: Keith Busch To: "Guilherme G. Piccoli" Cc: "linux-nvme@lists.infradead.org" , "linux-block@vger.kernel.org" , "axboe@fb.com" , "hch@lst.de" , "sagi@grimberg.me" , "jay.vosburgh@canonical.com" Subject: Re: [PATCH] nvme: Use first ctrl->instance id as subsystem id Message-ID: <20190814160640.GA3256@localhost.localdomain> References: <20190814142836.2322-1-gpiccoli@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190814142836.2322-1-gpiccoli@canonical.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Aug 14, 2019 at 07:28:36AM -0700, Guilherme G. Piccoli wrote: > Since after the introduction of NVMe multipath, we have a struct to > track subsystems, and more important, we have now the nvme block device > name bound to the subsystem id instead of ctrl->instance as before. > This is not a big problem, users can even fallback to the old behavior > using the module parameter "nvme_core.multipath=N" in case they don't > have multipath and wish to have a consistent mapping between the char > device nvmeX and the block device nvmeXnY. > > That said, we noticed the nvme subsystem id is generated by its own ID > allocator, and ctrl->instance value has itself an ID allocator too. > The controller instance is generated during the probe, in the function > nvme_init_ctrl(), which always executes before nvme_init_subsystem(). > That said, and since according to the spec we have a relation 1:N > between subsystem and controllers (i.e., one subsystem may have more > controllers but not the reciprocal), why not use the ctrl->instance id > as the subsystem id? The subsystem lifetime is not tied to a single controller's. Disconnect the "first" controller in a multipathed subsystem with this patch, then connect another controller from a different subsystem, and now you will create naming collisions. From mboxrd@z Thu Jan 1 00:00:00 1970 From: kbusch@kernel.org (Keith Busch) Date: Wed, 14 Aug 2019 10:06:41 -0600 Subject: [PATCH] nvme: Use first ctrl->instance id as subsystem id In-Reply-To: <20190814142836.2322-1-gpiccoli@canonical.com> References: <20190814142836.2322-1-gpiccoli@canonical.com> Message-ID: <20190814160640.GA3256@localhost.localdomain> On Wed, Aug 14, 2019@07:28:36AM -0700, Guilherme G. Piccoli wrote: > Since after the introduction of NVMe multipath, we have a struct to > track subsystems, and more important, we have now the nvme block device > name bound to the subsystem id instead of ctrl->instance as before. > This is not a big problem, users can even fallback to the old behavior > using the module parameter "nvme_core.multipath=N" in case they don't > have multipath and wish to have a consistent mapping between the char > device nvmeX and the block device nvmeXnY. > > That said, we noticed the nvme subsystem id is generated by its own ID > allocator, and ctrl->instance value has itself an ID allocator too. > The controller instance is generated during the probe, in the function > nvme_init_ctrl(), which always executes before nvme_init_subsystem(). > That said, and since according to the spec we have a relation 1:N > between subsystem and controllers (i.e., one subsystem may have more > controllers but not the reciprocal), why not use the ctrl->instance id > as the subsystem id? The subsystem lifetime is not tied to a single controller's. Disconnect the "first" controller in a multipathed subsystem with this patch, then connect another controller from a different subsystem, and now you will create naming collisions.