Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1369234ybf; Thu, 27 Feb 2020 09:38:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyRqq6ehQfrWBv+2jjrUWOT0MHTN1cydEISvAG5ycapYPwekH6sYsTIl4tc+g/QVKliA17M X-Received: by 2002:aca:220c:: with SMTP id b12mr104730oic.55.1582825100544; Thu, 27 Feb 2020 09:38:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582825100; cv=none; d=google.com; s=arc-20160816; b=uWjXbfINDf+mEi8/Dcji7a1HJe+mm3KpughFlAMCvYdKiZ6jO0hKURgmw6kIOBc5zO ZxKusOXzPcz53zCqtMCq4wWw8PSmLPFsyP1B7rVGDrIRhhdID2F6Mh8CD3i5X2Bg4du2 nTSWBM0kOZbV4l9wDHazrNhGQnGXkqun1E3KvEyRpqO5A+kPgTHTXrmWWRjDQfL2UnD4 JCcHm4eDGt5w5a8aFK0XvW0C9XBDfh5DlJufzbQ+z+rZkxYLsEiiaL3B3GhbcVs6gWEo 336JJeX6+R3+fm0rGyjPA8ptgjcn9s4o72Q4ozuvF5mN9gKMKxEvVFC9HTU5/8oH0pjh v4uQ== 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=mSzE+ZvVJ195S8LE39UCKqjLWN4d/Lb/cZqR4a8FXMk=; b=yudXOJP1zhtGiRs1f+tdxRwJluxs0Lh8zMtvw3WagnbzzSaTDk2pKcoqSK8Ch6eCB3 jnSeWb62Iy8G59sdJB7a8MEZxU140xsBDebu8QIRv0P4YQblQ5AUnCKkqMBvGua9hyGf sRwSGTr+pFZfkYG+bKme0Z6Y8XdP7rZbjxWEcjMDJu7XqqGi5JM0vBeXl2JM9yCUpx+s 1nFK82RodQEV4DhG/SuTdiQ+NBJWXrGMhtUlpCZQuzNLemSOCT5XpP8RXeLsUbrGWF54 XBkWk36HFkGxhThmXNMr0yNz/0lxb8c34ptwr64+38GwpdsGKovxhEibtmB/i3WDVAaB suiQ== 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 v25si2221092oth.274.2020.02.27.09.38.06; Thu, 27 Feb 2020 09:38:20 -0800 (PST) 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 S1730266AbgB0Rhc (ORCPT + 99 others); Thu, 27 Feb 2020 12:37:32 -0500 Received: from ale.deltatee.com ([207.54.116.67]:56838 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729232AbgB0Rhb (ORCPT ); Thu, 27 Feb 2020 12:37:31 -0500 Received: from s0106ac1f6bb1ecac.cg.shawcable.net ([70.73.163.230] helo=[192.168.11.155]) by ale.deltatee.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j7N6B-00040E-8O; Thu, 27 Feb 2020 10:37:23 -0700 To: Sagi Grimberg , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org Cc: Christoph Hellwig , Keith Busch , Jens Axboe , Chaitanya Kulkarni , Max Gurtovoy , Stephen Bates References: <20200220203652.26734-1-logang@deltatee.com> <20200220203652.26734-9-logang@deltatee.com> <96234649-fbc1-fb56-54d8-2f73dc455ffd@grimberg.me> From: Logan Gunthorpe Message-ID: <9c6355d8-cf4e-9932-1cef-0a7140f0fa7e@deltatee.com> Date: Thu, 27 Feb 2020 10:37:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <96234649-fbc1-fb56-54d8-2f73dc455ffd@grimberg.me> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 70.73.163.230 X-SA-Exim-Rcpt-To: sbates@raithlin.com, maxg@mellanox.com, Chaitanya.Kulkarni@wdc.com, axboe@fb.com, kbusch@kernel.org, hch@lst.de, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, sagi@grimberg.me 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=-6.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYRULES_FREE autolearn=no autolearn_force=no version=3.4.2 Subject: Re: [PATCH v11 8/9] nvmet-passthru: Add enable/disable helpers X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +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 2020-02-26 4:33 p.m., Sagi Grimberg wrote: > >> +    if (subsys->ver < NVME_VS(1, 2, 1)) { >> +        pr_warn("nvme controller version is too old: %d.%d.%d, >> advertising 1.2.1\n", >> +            (int)NVME_MAJOR(subsys->ver), >> +            (int)NVME_MINOR(subsys->ver), >> +            (int)NVME_TERTIARY(subsys->ver)); >> +        subsys->ver = NVME_VS(1, 2, 1); > > Umm.. is this OK? do we implement the mandatory 1.2.1 features on behalf > of the passthru device? This was the approach that Christoph suggested. It seemed sensible to me. However, it would also *probably* be ok to just reject these devices. Unless you feel strongly about this, I'll probably leave it the way it is. >> +    } >> + >> +    mutex_unlock(&subsys->lock); >> +    return 0; >> + >> +out_put_ctrl: >> +    nvme_put_ctrl(ctrl); >> +out_unlock: >> +    mutex_unlock(&subsys->lock); >> +    return ret; >> +} >> + >> +static void __nvmet_passthru_ctrl_disable(struct nvmet_subsys *subsys) >> +{ >> +    if (subsys->passthru_ctrl) { >> +        xa_erase(&passthru_subsystems, subsys->passthru_ctrl->cntlid); >> +        nvme_put_ctrl(subsys->passthru_ctrl); >> +    } >> +    subsys->passthru_ctrl = NULL; >> +    subsys->ver = NVMET_DEFAULT_VS; >> +} > > Isn't it strange that a subsystem changes its version in its lifetime? It does seem strange. However, it's not at all unprecedented. See nvmet_subsys_attr_version_store() which gives the user direct control of the version through configfs. >> + >> +void nvmet_passthru_ctrl_disable(struct nvmet_subsys *subsys) >> +{ >> +    mutex_lock(&subsys->lock); >> +    __nvmet_passthru_ctrl_disable(subsys); >> +    mutex_unlock(&subsys->lock); >> +} >> + >> +void nvmet_passthru_subsys_free(struct nvmet_subsys *subsys) >> +{ >> +    mutex_lock(&subsys->lock); >> +    __nvmet_passthru_ctrl_disable(subsys); >> +    kfree(subsys->passthru_ctrl_path); >> +    mutex_unlock(&subsys->lock); > > Nit, any reason why the free is in the mutex? Nope. Will fix.