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: Fri, 27 Aug 2021 02:39:23 +0000 [thread overview]
Message-ID: <d6cbd8d362ae84dde2ccde6698be0d3c@linux.dev> (raw)
In-Reply-To: <CAL_Jsq+rRFJUO3SVLdkQV62dQPymPigiikM05Xipgfbvg_oeqw@mail.gmail.com>
August 26, 2021 8:01 PM, "Rob Herring" <robh@kernel.org> wrote:
> On Wed, Aug 25, 2021 at 10:57 PM <yajun.deng@linux.dev> wrote:
>
>> 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().
>
> And that is the wrong order as we want to undo what the code above
> did. The put_device here is for the get_device we did. The put_device
> in device_unregister is for the get_device that device_register did
> (on success only).
>
> Logically, it is wrong too to call unregister if register failed. That
> would be like doing this:
>
> p = malloc(1);
> if (!p)
> free(p);
>
This is the raw code:
err = device_register(&bus->dev);
if (err)
goto unregister;
unregister:
put_device(&bridge->dev);
device_del(&bridge->dev);
This is my code:
err = device_register(&bus->dev);
if (err)
goto unregister;
unregister:
device_unregister(&bridge->dev);
The parameter in device_register() is bus->dev, but the parameter in device_unregister() is bridge->dev.The are different.
The bridge->dev is already success before called device_register().So it wouldn't be happen like your code.
> Rob
next prev parent reply other threads:[~2021-08-27 2:39 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
2021-08-26 12:01 ` Rob Herring
2021-08-27 2:39 ` yajun.deng [this message]
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=d6cbd8d362ae84dde2ccde6698be0d3c@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.