All of lore.kernel.org
 help / color / mirror / Atom feed
From: yajun.deng@linux.dev
To: "Rob Herring" <robh@kernel.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"PCI" <linux-pci@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH linux-next] PCI: Fix the order in unregister path
Date: Thu, 26 Aug 2021 03:57:40 +0000	[thread overview]
Message-ID: <63e1e9ea1e4b74b56aeafcc6695ecfa8@linux.dev> (raw)
In-Reply-To: <CAL_JsqJ4731w_0rYCSBC_Mma-rn4nUUbKnSwhymGZyh8E7xoWg@mail.gmail.com>

August 25, 2021 9:55 PM, "Rob Herring" <robh@kernel.org> wrote:

> On Wed, Aug 25, 2021 at 3:34 AM Yajun Deng <yajun.deng@linux.dev> wrote:
> 
>> device_del() should be called first and then called put_device() in
>> unregister path, becase if that the final reference count, the device
>> will be cleaned up via device_release() above. So use device_unregister()
>> instead.
>> 
>> Fixes: 9885440b16b8 (PCI: Fix pci_host_bridge struct device release/free handling)
>> Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
>> ---
>> drivers/pci/probe.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> NAK.
> 
> The current code is correct. Go read the comments for device_add/device_del.

But the device_unregister() is only contains device_del() and put_device(). It just put
device_del() before put_device().

> 
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 0ec5c792c27d..abd481a15a17 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -994,9 +994,7 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge)
>> return 0;
>> 
>> unregister:
> 
> We get here if device_register() failed. Calling device_unregister()
> in that case is never right.
> 
>> - put_device(&bridge->dev);
> 
> This is for the get_device() we do above, not the get the driver core does.
> 
>> - device_del(&bridge->dev);
> 
> This undoes the device_add() we do following the comment: "NOTE: this
> should be called manually _iff_ device_add() was also called
> manually."
> 
>> -
>> + device_unregister(&bridge->dev);
>> free:
>> kfree(bus);
>> return err;
>> --
>> 2.32.0

  reply	other threads:[~2021-08-26  3:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  8:34 [PATCH linux-next] PCI: Fix the order in unregister path Yajun Deng
2021-08-25 13:55 ` Rob Herring
2021-08-26  3:57   ` yajun.deng [this message]
2021-08-26 12:01     ` Rob Herring
2021-08-27  2:39       ` yajun.deng
2021-08-30 14:55         ` Rob Herring
2021-08-31  2:41           ` yajun.deng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63e1e9ea1e4b74b56aeafcc6695ecfa8@linux.dev \
    --to=yajun.deng@linux.dev \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.