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: Tue, 31 Aug 2021 02:41:42 +0000 [thread overview]
Message-ID: <4186a73958319066f76c8a7e2e833b2a@linux.dev> (raw)
In-Reply-To: <CAL_JsqKNOFhfs3=xpsLZRTaNKEnGPTKU58mDJU7AfuAwMdLrmw@mail.gmail.com>
August 30, 2021 10:55 PM, "Rob Herring" <robh@kernel.org> wrote:
> On Thu, Aug 26, 2021 at 9:39 PM <yajun.deng@linux.dev> wrote:
>
>> 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:
>
> You are right that the register and unregister are different devices.
> However, your change is still wrong. The device_register is actually
> irrelevant.
>
OK, the original order is right, it was my mistake.
>> 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);
>
> The pertinent parts are this:
>
> err = device_add(&bridge->dev); // which calls get_device() itself,
> so there's the first ref
> if (err) {
> put_device(&bridge->dev);
> goto free;
> }
> bus->bridge = get_device(&bridge->dev); // This is the 2nd ref which
> the PCI core holds
> ...
> unregister:
> put_device(&bridge->dev); // This is the put for the get_device
> just above here.
> device_del(&bridge->dev); // Then this does the 2nd put.
>
> The get_device and put_device are paired, and the device_add and
> device_del are paired.
>
> As I said earlier, go read the kerneldoc for device_add. For your
> convenience, here's the important part:
>
> device_add:
> * Rule of thumb is: if device_add() succeeds, you should call
> * device_del() when you want to get rid of it. If device_add() has
> * *not* succeeded, use *only* put_device() to drop the reference
> * count.
>
> device_del:
> * NOTE: this should be called manually _iff_ device_add() was
> * also called manually.
>
> Rob
prev parent reply other threads:[~2021-08-31 2:41 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
2021-08-30 14:55 ` Rob Herring
2021-08-31 2:41 ` yajun.deng [this message]
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=4186a73958319066f76c8a7e2e833b2a@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.