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
next prev parent 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.