All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jike Song <jike.song@intel.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: alex.williamson@redhat.com, pbonzini@redhat.com,
	kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, kevin.tian@intel.com, shuai.ruan@intel.com,
	zhiyuan.lv@intel.com, bjsdjshi@linux.vnet.ibm.com
Subject: Re: [PATCH 1/3] Mediated device Core driver
Date: Mon, 04 Jul 2016 10:08:01 +0800	[thread overview]
Message-ID: <5779C501.2050702@intel.com> (raw)
In-Reply-To: <1466440308-4961-2-git-send-email-kwankhede@nvidia.com>

On 06/21/2016 12:31 AM, Kirti Wankhede wrote:
> +/*
> + * mdev_register_device : Register a device
> + * @dev: device structure representing parent device.
> + * @ops: Parent device operation structure to be registered.
> + *
> + * Add device to list of registered parent devices.
> + * Returns a negative value on error, otherwise 0.
> + */
> +int mdev_register_device(struct device *dev, const struct parent_ops *ops)
> +{
> +	int ret = 0;
> +	struct parent_device *parent;
> +
> +	if (!dev || !ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&parent_devices.list_lock);
> +
> +	/* Check for duplicate */
> +	parent = find_parent_device(dev);
> +	if (parent) {
> +		ret = -EEXIST;
> +		goto add_dev_err;
> +	}
> +
> +	parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> +	if (!parent) {
> +		ret = -ENOMEM;
> +		goto add_dev_err;
> +	}
> +
> +	kref_init(&parent->ref);
> +	list_add(&parent->next, &parent_devices.dev_list);
> +	mutex_unlock(&parent_devices.list_lock);
> +
> +	parent->dev = dev;
> +	parent->ops = ops;
> +	mutex_init(&parent->ops_lock);
> +	mutex_init(&parent->mdev_list_lock);
> +	INIT_LIST_HEAD(&parent->mdev_list);
> +	init_waitqueue_head(&parent->release_done);
> +
> +	ret = mdev_create_sysfs_files(dev);
> +	if (ret)
> +		goto add_sysfs_error;
> +
> +	ret = mdev_add_attribute_group(dev, ops->dev_attr_groups);
> +	if (ret)
> +		goto add_group_error;
> +
> +	dev_info(dev, "MDEV: Registered\n");
> +	return 0;
> +
> +add_group_error:
> +	mdev_remove_sysfs_files(dev);
> +add_sysfs_error:
> +	mutex_lock(&parent_devices.list_lock);
> +	list_del(&parent->next);
> +	mutex_unlock(&parent_devices.list_lock);
> +	mdev_put_parent(parent);
> +	return ret;
> +
> +add_dev_err:
> +	mutex_unlock(&parent_devices.list_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL(mdev_register_device);
> +
...
> +static int __init mdev_init(void)
> +{
> +	int ret;
> +
> +	mutex_init(&parent_devices.list_lock);
> +	INIT_LIST_HEAD(&parent_devices.dev_list);
> +
> +	ret = class_register(&mdev_class);
> +	if (ret) {
> +		pr_err("Failed to register mdev class\n");
> +		return ret;
> +	}
> +
> +	ret = mdev_bus_register();
> +	if (ret) {
> +		pr_err("Failed to register mdev bus\n");
> +		class_unregister(&mdev_class);
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static void __exit mdev_exit(void)
> +{
> +	mdev_bus_unregister();
> +	class_unregister(&mdev_class);
> +}
> +
> +module_init(mdev_init)
> +module_exit(mdev_exit)

Hi Kirti,

I have a question about the order of initialization,

	phy_driver calls mdev_register_device in its __init function;
	mdev_register_device accesses parent_devices.list_lock;
	parent.list_lock is initialized in __init of mdev;

The __init function of both phy driver and mdev are classified with
module_init, if they are selected to be 'Y' in .config, it's possible that in
mdev_register_device(), the mutex is still uninitialized.

The problem here I think is both mdev and phy driver are actually *drivers*,
so once they are builtin, the initialization order is hard to assume.

Do you have any idea to avoid this? Thanks!

 
--
Thanks,
Jike


WARNING: multiple messages have this Message-ID (diff)
From: Jike Song <jike.song@intel.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: alex.williamson@redhat.com, pbonzini@redhat.com,
	kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, kevin.tian@intel.com, shuai.ruan@intel.com,
	zhiyuan.lv@intel.com, bjsdjshi@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 1/3] Mediated device Core driver
Date: Mon, 04 Jul 2016 10:08:01 +0800	[thread overview]
Message-ID: <5779C501.2050702@intel.com> (raw)
In-Reply-To: <1466440308-4961-2-git-send-email-kwankhede@nvidia.com>

On 06/21/2016 12:31 AM, Kirti Wankhede wrote:
> +/*
> + * mdev_register_device : Register a device
> + * @dev: device structure representing parent device.
> + * @ops: Parent device operation structure to be registered.
> + *
> + * Add device to list of registered parent devices.
> + * Returns a negative value on error, otherwise 0.
> + */
> +int mdev_register_device(struct device *dev, const struct parent_ops *ops)
> +{
> +	int ret = 0;
> +	struct parent_device *parent;
> +
> +	if (!dev || !ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&parent_devices.list_lock);
> +
> +	/* Check for duplicate */
> +	parent = find_parent_device(dev);
> +	if (parent) {
> +		ret = -EEXIST;
> +		goto add_dev_err;
> +	}
> +
> +	parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> +	if (!parent) {
> +		ret = -ENOMEM;
> +		goto add_dev_err;
> +	}
> +
> +	kref_init(&parent->ref);
> +	list_add(&parent->next, &parent_devices.dev_list);
> +	mutex_unlock(&parent_devices.list_lock);
> +
> +	parent->dev = dev;
> +	parent->ops = ops;
> +	mutex_init(&parent->ops_lock);
> +	mutex_init(&parent->mdev_list_lock);
> +	INIT_LIST_HEAD(&parent->mdev_list);
> +	init_waitqueue_head(&parent->release_done);
> +
> +	ret = mdev_create_sysfs_files(dev);
> +	if (ret)
> +		goto add_sysfs_error;
> +
> +	ret = mdev_add_attribute_group(dev, ops->dev_attr_groups);
> +	if (ret)
> +		goto add_group_error;
> +
> +	dev_info(dev, "MDEV: Registered\n");
> +	return 0;
> +
> +add_group_error:
> +	mdev_remove_sysfs_files(dev);
> +add_sysfs_error:
> +	mutex_lock(&parent_devices.list_lock);
> +	list_del(&parent->next);
> +	mutex_unlock(&parent_devices.list_lock);
> +	mdev_put_parent(parent);
> +	return ret;
> +
> +add_dev_err:
> +	mutex_unlock(&parent_devices.list_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL(mdev_register_device);
> +
...
> +static int __init mdev_init(void)
> +{
> +	int ret;
> +
> +	mutex_init(&parent_devices.list_lock);
> +	INIT_LIST_HEAD(&parent_devices.dev_list);
> +
> +	ret = class_register(&mdev_class);
> +	if (ret) {
> +		pr_err("Failed to register mdev class\n");
> +		return ret;
> +	}
> +
> +	ret = mdev_bus_register();
> +	if (ret) {
> +		pr_err("Failed to register mdev bus\n");
> +		class_unregister(&mdev_class);
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static void __exit mdev_exit(void)
> +{
> +	mdev_bus_unregister();
> +	class_unregister(&mdev_class);
> +}
> +
> +module_init(mdev_init)
> +module_exit(mdev_exit)

Hi Kirti,

I have a question about the order of initialization,

	phy_driver calls mdev_register_device in its __init function;
	mdev_register_device accesses parent_devices.list_lock;
	parent.list_lock is initialized in __init of mdev;

The __init function of both phy driver and mdev are classified with
module_init, if they are selected to be 'Y' in .config, it's possible that in
mdev_register_device(), the mutex is still uninitialized.

The problem here I think is both mdev and phy driver are actually *drivers*,
so once they are builtin, the initialization order is hard to assume.

Do you have any idea to avoid this? Thanks!

 
--
Thanks,
Jike

  parent reply	other threads:[~2016-07-04  2:09 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 16:31 [RFC PATCH v5 0/3] Add Mediated device support Kirti Wankhede
2016-06-20 16:31 ` [Qemu-devel] " Kirti Wankhede
2016-06-20 16:31 ` [PATCH 1/3] Mediated device Core driver Kirti Wankhede
2016-06-20 16:31   ` [Qemu-devel] " Kirti Wankhede
2016-06-21  7:38   ` Jike Song
2016-06-21  7:38     ` [Qemu-devel] " Jike Song
2016-06-21 21:30   ` Alex Williamson
2016-06-21 21:30     ` [Qemu-devel] " Alex Williamson
2016-06-24 17:54     ` Kirti Wankhede
2016-06-24 17:54       ` [Qemu-devel] " Kirti Wankhede
2016-06-24 19:40       ` Alex Williamson
2016-06-24 19:40         ` [Qemu-devel] " Alex Williamson
2016-06-30 16:48         ` Kirti Wankhede
2016-06-30 16:48           ` [Qemu-devel] " Kirti Wankhede
2016-06-29 13:51   ` Xiao Guangrong
2016-06-29 13:51     ` [Qemu-devel] " Xiao Guangrong
2016-06-30  7:12     ` Jike Song
2016-06-30  7:12       ` [Qemu-devel] " Jike Song
2016-06-30 18:58       ` Kirti Wankhede
2016-06-30 18:58         ` Kirti Wankhede
2016-06-30 18:51     ` Kirti Wankhede
2016-06-30 18:51       ` Kirti Wankhede
2016-07-04  7:27       ` Xiao Guangrong
2016-07-04  2:08   ` Jike Song [this message]
2016-07-04  2:08     ` Jike Song
2016-06-20 16:31 ` [PATCH 2/3] VFIO driver for mediated PCI device Kirti Wankhede
2016-06-20 16:31   ` [Qemu-devel] " Kirti Wankhede
2016-06-21 22:48   ` Alex Williamson
2016-06-21 22:48     ` [Qemu-devel] " Alex Williamson
2016-06-24 18:34     ` Kirti Wankhede
2016-06-24 18:34       ` [Qemu-devel] " Kirti Wankhede
2016-06-24 19:45       ` Alex Williamson
2016-06-24 19:45         ` [Qemu-devel] " Alex Williamson
2016-06-28 18:45         ` Kirti Wankhede
2016-06-28 18:45           ` [Qemu-devel] " Kirti Wankhede
2016-06-29  2:54           ` Alex Williamson
2016-06-29  2:54             ` [Qemu-devel] " Alex Williamson
2016-06-30 16:54             ` Kirti Wankhede
2016-06-30 16:54               ` [Qemu-devel] " Kirti Wankhede
2016-06-30  6:34   ` Xiao Guangrong
2016-06-30  6:34     ` [Qemu-devel] " Xiao Guangrong
2016-06-20 16:31 ` [PATCH 3/3] VFIO Type1 IOMMU: Add support for mediated devices Kirti Wankhede
2016-06-20 16:31   ` [Qemu-devel] " Kirti Wankhede
2016-06-22  3:46   ` Alex Williamson
2016-06-22  3:46     ` [Qemu-devel] " Alex Williamson
2016-06-28 13:02     ` Kirti Wankhede
2016-06-28 13:02       ` [Qemu-devel] " Kirti Wankhede
2016-06-29  2:46       ` Alex Williamson
2016-06-29  2:46         ` [Qemu-devel] " Alex Williamson
2016-06-30  8:28         ` Tian, Kevin
2016-06-30  8:28           ` [Qemu-devel] " Tian, Kevin

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=5779C501.2050702@intel.com \
    --to=jike.song@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shuai.ruan@intel.com \
    --cc=zhiyuan.lv@intel.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 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.