All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yan Zhao <yan.y.zhao@intel.com>
To: alex.williamson@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	cohuck@redhat.com, zhenyuw@linux.intel.com, zhi.a.wang@intel.com,
	kevin.tian@intel.com, shaopeng.he@intel.com, yi.l.liu@intel.com,
	Yan Zhao <yan.y.zhao@intel.com>
Subject: [RFC PATCH v2 4/9] vfio/pci: macros to generate module_init and module_exit for vendor modules
Date: Thu, 30 Jan 2020 21:11:40 -0500	[thread overview]
Message-ID: <20200131021140.27774-1-yan.y.zhao@intel.com> (raw)
In-Reply-To: <20200131020803.27519-1-yan.y.zhao@intel.com>

vendor modules call macro module_vfio_pci_register_vendor_handler to
generate module_init and module_exit.
It is a must to ensure that vendor modules always call
vfio_pci_register_vendor_driver() on driver loading and
vfio_pci_unregister_vendor_driver on driver unloading,
because
(1) at compiling time, there's only a dependency of vendor modules on
vfio_pci.
(2) at runtime,
- vendor modules trigger module ref inc of vfio_pci when
  vfio_pci_register_vendor_driver() succeeds and module ref dec of vfio_pci
  when vfio_pci_unregister_vendor_driver() succeeds.
- vfio_pci adds refs of vendor module on a successful probe of vendor
  driver.
  vfio_pci derefs vendor module when unbinding from a device.

After vfio_pci is unbound from a device, the vendor module to that
device is free to get unloaded. However, if that vendor module does not
call vfio_pci_unregister_vendor_driver() before its module_exit, vfio_pc
may hold a stale pointer to vendor module and would be able to get unloaded
for the ref increased in vfio_pci_register_vendor_driver();

That's how module_vfio_pci_register_vendor_handler helps.

Suggested-by: Alex Williamson <alex.williamson@redhat.com>

Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
---
 include/linux/vfio.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 69519cf1fd4f..386d1b19da3d 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -226,4 +226,31 @@ extern int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma);
 extern void vfio_pci_request(void *device_data, unsigned int count);
 extern int vfio_pci_open(void *device_data);
 extern void vfio_pci_release(void *device_data);
+
+#define vfio_pci_register_vendor_driver(__name, __probe, __remove,	\
+					__device_ops)			\
+static struct vfio_pci_vendor_driver_ops  __ops ## _node = {		\
+	.owner		= THIS_MODULE,					\
+	.name		= __name,					\
+	.probe		= __probe,					\
+	.remove		= __remove,					\
+	.device_ops	= __device_ops,					\
+};									\
+__vfio_pci_register_vendor_driver(&__ops ## _node)
+
+#define module_vfio_pci_register_vendor_handler(name, probe, remove,	\
+						device_ops)		\
+static int __init device_ops ## _module_init(void)			\
+{									\
+	vfio_pci_register_vendor_driver(name, probe, remove,		\
+					device_ops);			\
+	return 0;							\
+};									\
+static void __exit device_ops ## _module_exit(void)			\
+{									\
+	vfio_pci_unregister_vendor_driver(device_ops);			\
+};									\
+module_init(device_ops ## _module_init);				\
+module_exit(device_ops ## _module_exit)
+
 #endif /* VFIO_H */
-- 
2.17.1


  parent reply	other threads:[~2020-01-31  2:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  2:08 [RFC PATCH v2 0/9] Introduce vendor ops in vfio-pci Yan Zhao
2020-01-31  2:09 ` [RFC PATCH v2 1/9] vfio/pci: split vfio_pci_device into public and private parts Yan Zhao
2020-02-07 19:48   ` Alex Williamson
2020-02-10  0:34     ` Yan Zhao
2020-01-31  2:10 ` [RFC PATCH v2 2/9] vfio/pci: export functions in vfio_pci_ops Yan Zhao
2020-01-31  2:11 ` [RFC PATCH v2 3/9] vfio/pci: register/unregister vfio_pci_vendor_driver_ops Yan Zhao
2020-01-31  2:11 ` Yan Zhao [this message]
2020-01-31  2:12 ` [RFC PATCH v2 5/9] vfio/pci: let vfio_pci know how many vendor regions are registered Yan Zhao
2020-01-31  2:12 ` [RFC PATCH v2 6/9] vfio/pci: export vfio_pci_setup_barmap Yan Zhao
2020-01-31  2:13 ` [RFC PATCH v2 7/9] samples/vfio-pci: add a sample vendor module of vfio-pci for IGD devices Yan Zhao
2020-01-31  2:13 ` [RFC PATCH v2 8/9] vfio: header for vfio live migration region Yan Zhao
2020-01-31  2:13 ` [RFC PATCH v2 9/9] i40e/vf_migration: vfio-pci vendor driver for VF live migration Yan Zhao

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=20200131021140.27774-1-yan.y.zhao@intel.com \
    --to=yan.y.zhao@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaopeng.he@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@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.