Received: by 10.192.165.148 with SMTP id m20csp3750411imm; Mon, 23 Apr 2018 11:41:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx49oTY6jDseBUsmA383JJVHxTYIB9H44fNMT4KPe8F/JNenusRi/h3tNpfr/UEo4/dTti81O X-Received: by 10.99.110.4 with SMTP id j4mr18190261pgc.345.1524508873351; Mon, 23 Apr 2018 11:41:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524508873; cv=none; d=google.com; s=arc-20160816; b=oNX8RZ/O/ij51hZKu50I4KBRopVJnX56by/t05hPHQbrfwm5AOrq4hylKgaR0GS8NH KQg7cK4e7Salq4LjavnVMfjMKkexCtCCMuGVq26qd+BHjo4uVzyjLT6zZJI4bbFVO2SF NJStQJZ1j6wEDVS5q/4pcLxbZRFAllcQm3f59QVW8NtwcFBOjmA2AqZvimN4jeUNTGNS rlOZXrgD/tgdz4Ta+JP5CZRjs79mJ+wVl06XdDU8tu/N+ImiCbF1v1MgaMNycdps71Sf SqmTzRJg+ykkuWmtAiCChszjjJ6oYemmQqhaLhClU+GL9AOHXr42ecGDBD3nFXJyUs8+ pA3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=47pT7YQVkcjrQLkYfu2LFhqn7aYJSvPAP8ZAgCGdG7U=; b=mvnEI2oyS7wKxivubIkBP8oVJHHIaGlPF9l9iOQuBa66nlPLJ3jxxFfBIJ2/FEhpFb rhM3uFRtWZEIGgj2WlN43eerlp3tcy8ceMPHLRjqJPWUxRh+ROqJMpe8XLHK+c7VlP0T bKdwJq8NQzjkAm9xNvbQfJ4onp52iFony2poM5sp+hm6eFwSrdibnKnQt+I3HCDLXKua eAYfHHdHdhSvEbRUMDHAOpCGJFk/EOXKLncNEJf3Xf3leu+fIbCs6K2jY8W4gX8TcLOl TV7uLONSdHCgx9+mHL2dR9Dk0UvposlvBsDVr6y1FyuHSsEyghXcV5TKFHdK7K9+8plh 6IEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LUfMDwPE; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t5si4324600pgp.594.2018.04.23.11.40.45; Mon, 23 Apr 2018 11:41:13 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LUfMDwPE; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932347AbeDWSiy (ORCPT + 99 others); Mon, 23 Apr 2018 14:38:54 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:46638 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932085AbeDWSiw (ORCPT ); Mon, 23 Apr 2018 14:38:52 -0400 Received: by mail-pf0-f193.google.com with SMTP id h69so10023723pfe.13; Mon, 23 Apr 2018 11:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=47pT7YQVkcjrQLkYfu2LFhqn7aYJSvPAP8ZAgCGdG7U=; b=LUfMDwPEBmgryK/k0FQtOrcbEOMc/mM2eTaSfBe54mwoW9j2LCR8sojuagfoeHrekn h6VBYzzXjcc5n331oKzsFDSfz5dfg0CRfP3AiOJpqPASNhHYSbSmCSZEJpptlJBygIxS 3mSCUbF3G/8xQnDtw47TnwlHNW5o8xGh9sPqbk+owrcn4UjVAXqaW0hU2aV9vHVOGK15 LcgmLLGVHLV/50J/czGNziTQkSd7v3EZDrdi51zLcGzoRI3tZ5JzbdB/O9IEqZi//a4i Bpiag/RpAs/k67GWMpckQt+hBFGhTopUrY/VeCLWoZr1qAQzPprtcyEWt9FevLnlHF1O IPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=47pT7YQVkcjrQLkYfu2LFhqn7aYJSvPAP8ZAgCGdG7U=; b=fmbkFjUc3kLx3C244HchRR4MReVB4e0B9+cGtWieNKIU27TR2a8jNgqqcoAfamXwCh No/HvWC8pE40yIsnUgqFGjqfNX2LdPb/MXGlo1WDuDFtLUmVpF7lexsu5gfedGFOJqFy bS2/tbEQ1OyzZ2FNeCDMG0AyO3CtUQAbjvykbsDFBgIaXwMXPlZZEtFr/q+AfziEpc49 SXUzjDHUdNiThK0R+5+gd1+EfNyI5KhayCrV1WQ82iFY47mlKneBHSbbygSDs25r8EBT w3QTm5EB0lDVgVN2Gt41IjBvjKAjq4Dhx7+B66YbPHIHGS1x8At+d9GNXoOu387QJx1Y eTFw== X-Gm-Message-State: ALQs6tDDxX3AEInPRZmM+mxMWX78/B27RKVXgY3nw0Wka3xxQKpATfdm D+I2zwfXrPBln8bhGhuaFcI= X-Received: by 2002:a17:902:9890:: with SMTP id s16-v6mr22007116plp.132.1524508731598; Mon, 23 Apr 2018 11:38:51 -0700 (PDT) Received: from xldev-tmpl.dev.purestorage.com ([192.30.188.252]) by smtp.gmail.com with ESMTPSA id v8sm1018890pff.89.2018.04.23.11.38.50 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 23 Apr 2018 11:38:51 -0700 (PDT) Date: Mon, 23 Apr 2018 12:38:48 -0600 From: Anatoliy Glagolev To: James Bottomley Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org, axboe@kernel.dk, fujita.tomonori@lab.ntt.co.jp, martin.petersen@oracle.com, jthumshirn@suse.de, hare@suse.com, bblock@linux.vnet.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] bsg referencing bus driver module Message-ID: <20180423183845.GA21609@xldev-tmpl.dev.purestorage.com> References: <1524218126.3321.6.camel@HansenPartnership.com> <20180420224404.GC32372@xldev-tmpl.dev.purestorage.com> <1524383279.3389.7.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1524383279.3389.7.camel@HansenPartnership.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks, James. The idea of cutting communications with Scsi_Host at bsg_unregister_queue(..) time and leaving bsg_class_device to its own fate makes a lot of sense, conceptually. But there are implementation issues that are difficult to work around. bsg.c creates bsg_class_device and takes a reference to Scsi_Host at bsg_register_queue(..) time. The reference is dropped at bsg_class_device's release(..) function. If the driver implementing Scsi_Host template is not around we crash. We could move the reference drop from bsg_class_device's release(..) function to bsg_unregister_queue(..). That would be a small change in bsg.c. But bsg.c sets Scsi_Host as the parent of bsg_class_device's device. We cannot have a device around with a dangling parent. A device's parent cannot be changed dynamically. Not setting the device's parent at creation may affect software relying on bsg_class_device - Scsi_Host child-parent relations. It looks like I am out of options. Do you have suggestions on how to work around Scsi_Host being bsg_class_device's parent?