From: Jason Gunthorpe <jgg@mellanox.com>
To: Selvin Xavier <selvin.xavier@broadcom.com>
Cc: dledford@redhat.com, linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-next v2 3/3] RDMA/bnxt_re: Use driver_unregister and unregistration API
Date: Mon, 24 Feb 2020 09:43:38 -0400 [thread overview]
Message-ID: <20200224134338.GH26318@mellanox.com> (raw)
In-Reply-To: <1582541395-19409-4-git-send-email-selvin.xavier@broadcom.com>
On Mon, Feb 24, 2020 at 02:49:55AM -0800, Selvin Xavier wrote:
>
> @@ -1785,32 +1777,23 @@ static int __init bnxt_re_mod_init(void)
>
> static void __exit bnxt_re_mod_exit(void)
> {
> - struct bnxt_re_dev *rdev, *next;
> - LIST_HEAD(to_be_deleted);
> + struct bnxt_re_dev *rdev;
>
> + flush_workqueue(bnxt_re_wq);
What is this for? Usually flushing a work queue before preventing new
work from queueing (ie via unregister) is racy.
> mutex_lock(&bnxt_re_dev_lock);
> - /* Free all adapter allocated resources */
> - if (!list_empty(&bnxt_re_dev_list))
> - list_splice_init(&bnxt_re_dev_list, &to_be_deleted);
> - mutex_unlock(&bnxt_re_dev_lock);
> - /*
> - * Cleanup the devices in reverse order so that the VF device
> - * cleanup is done before PF cleanup
> - */
> - list_for_each_entry_safe_reverse(rdev, next, &to_be_deleted, list) {
> - ibdev_info(&rdev->ibdev, "Unregistering Device");
> - /*
> - * Flush out any scheduled tasks before destroying the
> - * resources
> + list_for_each_entry(rdev, &bnxt_re_dev_list, list) {
> + /* VF device removal should be called before the removal
> + * of PF device. Queue VFs unregister first, so that VFs
> + * shall be removed before the PF during the call of
> + * ib_unregister_driver. Commands to any VFs after the
> + * PF removal will timeout and driver will proceed with
> + * unregisteration and free up the host resources.
> */
> - flush_workqueue(bnxt_re_wq);
> - bnxt_re_dev_stop(rdev);
> - bnxt_re_ib_uninit(rdev);
> - /* Acquire the rtnl_lock as the L2 resources are freed here */
> - rtnl_lock();
> - bnxt_re_remove_device(rdev);
> - rtnl_unlock();
> + if (rdev->is_virtfn)
> + ib_unregister_device_queued(&rdev->ibdev);
Why do it queued? Just call ib_unregister_device(). Otherwise it won't
order reliably.
But be very careful about lifetime. All the other drivers had problems
managing the lifetime of the pointers in their device lists.
Jason
next prev parent reply other threads:[~2020-02-24 13:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 10:49 [PATCH for-next v2 0/3] RDMA/bnxt_re driver update Selvin Xavier
2020-02-24 10:49 ` [PATCH for-next v2 1/3] RDMA/bnxt_re: Add more flags in device init and uninit path Selvin Xavier
2020-02-24 13:48 ` Jason Gunthorpe
2020-02-25 10:14 ` Selvin Xavier
2020-02-24 10:49 ` [PATCH for-next v2 2/3] RDMA/bnxt_re: Refactor device add/remove functionalities Selvin Xavier
2020-02-24 13:53 ` Jason Gunthorpe
2020-02-25 4:22 ` Selvin Xavier
2020-02-24 10:49 ` [PATCH for-next v2 3/3] RDMA/bnxt_re: Use driver_unregister and unregistration API Selvin Xavier
2020-02-24 13:43 ` Jason Gunthorpe [this message]
2020-02-25 4:10 ` Selvin Xavier
2020-02-25 13:16 ` Jason Gunthorpe
2020-02-25 15:52 ` Selvin Xavier
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=20200224134338.GH26318@mellanox.com \
--to=jgg@mellanox.com \
--cc=dledford@redhat.com \
--cc=linux-rdma@vger.kernel.org \
--cc=selvin.xavier@broadcom.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).