search for: module_exit

There is a typo here, "i" vs "j", so we would crash on module_exit(). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index a0b50ad..130bcb2 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1968,8 +1968,8 @@ static void __exi...

...,9 @@ module_init(virtio_net_driver_init); static __exit void virtio_net_driver_exit(void) { + unregister_virtio_driver(&virtio_net_driver); cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD); cpuhp_remove_multi_state(virtionet_online); - unregister_virtio_driver(&virtio_net_driver); } module_exit(virtio_net_driver_exit); -- 2.13.3

...,9 @@ module_init(virtio_net_driver_init); static __exit void virtio_net_driver_exit(void) { + unregister_virtio_driver(&virtio_net_driver); cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD); cpuhp_remove_multi_state(virtionet_online); - unregister_virtio_driver(&virtio_net_driver); } module_exit(virtio_net_driver_exit); -- 2.13.3

...+ +static void __exit hv_pci_exit(void) +{ + vmbus_bus_exit(); + pci_unregister_driver(&platform_driver); +} + + + MODULE_LICENSE("GPL"); MODULE_VERSION(HV_DRV_VERSION); module_param(vmbus_irq, int, S_IRUGO); module_param(vmbus_loglevel, int, S_IRUGO); -module_init(vmbus_init); -module_exit(vmbus_exit); +module_init(hv_pci_init); +module_exit(hv_pci_exit); -- 1.5.5.6

...+ +static void __exit hv_pci_exit(void) +{ + vmbus_bus_exit(); + pci_unregister_driver(&platform_driver); +} + + + MODULE_LICENSE("GPL"); MODULE_VERSION(HV_DRV_VERSION); module_param(vmbus_irq, int, S_IRUGO); module_param(vmbus_loglevel, int, S_IRUGO); -module_init(vmbus_init); -module_exit(vmbus_exit); +module_init(hv_pci_init); +module_exit(hv_pci_exit); -- 1.5.5.6

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we can't call vsock_core_exit() until there are open sockets. v2 -> v3: - Rebased...

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we can't call vsock_core_exit() until there are open sockets. v2 -> v3: - Rebased...

Hi, The following patches fix couple of memory leaks in the virtio and remoteproc cores when using these as modules, and going through a cycle of insmod and rmmod with at least a device registered with the corresponding cores in between. I ran into this on our downstream product kernels on both 3.14 and 4.1 based kernels, and should apply to the latest kernel as well. Patches can be picked up

Hi, The following patches fix couple of memory leaks in the virtio and remoteproc cores when using these as modules, and going through a cycle of insmod and rmmod with at least a device registered with the corresponding cores in between. I ran into this on our downstream product kernels on both 3.14 and 4.1 based kernels, and should apply to the latest kernel as well. Patches can be picked up

...nged, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c > index d7eaf1eb11e7..003bfba40758 100644 > --- a/drivers/misc/vmw_vmci/vmci_driver.c > +++ b/drivers/misc/vmw_vmci/vmci_driver.c > @@ -113,5 +113,5 @@ module_exit(vmci_drv_exit); > > MODULE_AUTHOR("VMware, Inc."); > MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface."); > -MODULE_VERSION("1.1.5.0-k"); > +MODULE_VERSION("1.1.6.0-k"); > MODULE_LICENSE("GPL v2"); You do kn...

...nged, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c > index d7eaf1eb11e7..003bfba40758 100644 > --- a/drivers/misc/vmw_vmci/vmci_driver.c > +++ b/drivers/misc/vmw_vmci/vmci_driver.c > @@ -113,5 +113,5 @@ module_exit(vmci_drv_exit); > > MODULE_AUTHOR("VMware, Inc."); > MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface."); > -MODULE_VERSION("1.1.5.0-k"); > +MODULE_VERSION("1.1.6.0-k"); > MODULE_LICENSE("GPL v2"); You do kn...

...just asked. Best regards Thomas Am 13.08.2018 um 12:33 schrieb Christian König: > Yes, please! I had it on my TODO list to clean that up for an eternity. > > Actually I never understood why that should be driver work to setup TTM? > > I mean can't we just have a module_init/module_exit for TTM? > > Thanks, > Christian. > > Am 13.08.2018 um 12:24 schrieb Thomas Zimmermann: >> TTM uses global memory and BO for backing graphics buffers. These are >> represented by struct ttm_mem_global and struct ttm_bo_global. >> >> Currently, struct ttm_bo_...

...d vsock_core_unregister(const struct vsock_transport *t) > +{ > + mutex_lock(&vsock_register_mutex); > + > + /* RFC-TODO: maybe we should check if there are open sockets > + * assigned to that transport and avoid the unregistration > + */ If unregister() is only called from module_exit() functions then holding a reference to the transport module would be enough to prevent this case. The transport could only be removed once all sockets have been destroyed (and dropped their transport module reference). -------------- next part -------------- A non-text attachment was scrubbed......

Yes, please! I had it on my TODO list to clean that up for an eternity. Actually I never understood why that should be driver work to setup TTM? I mean can't we just have a module_init/module_exit for TTM? Thanks, Christian. Am 13.08.2018 um 12:24 schrieb Thomas Zimmermann: > TTM uses global memory and BO for backing graphics buffers. These are > represented by struct ttm_mem_global and struct ttm_bo_global. > > Currently, struct ttm_bo_global can only be initialized and releas...

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

....remove = vfio_vhost_mdev_remove, }; static int __init vfio_vhost_mdev_init(void) { return mdev_register_driver(&vfio_vhost_mdev_driver, THIS_MODULE); } module_init(vfio_vhost_mdev_init) static void __exit vfio_vhost_mdev_exit(void) { mdev_unregister_driver(&vfio_vhost_mdev_driver); } module_exit(vfio_vhost_mdev_exit) > > So I have some questions: > > 1) Compared to method 2, what's the advantage of creating a new vhost char > device? I guess it's for keep the API compatibility? One benefit is that we can avoid doing vhost ioctls on VFIO device fd. > > 2)...

....remove = vfio_vhost_mdev_remove, }; static int __init vfio_vhost_mdev_init(void) { return mdev_register_driver(&vfio_vhost_mdev_driver, THIS_MODULE); } module_init(vfio_vhost_mdev_init) static void __exit vfio_vhost_mdev_exit(void) { mdev_unregister_driver(&vfio_vhost_mdev_driver); } module_exit(vfio_vhost_mdev_exit) > > So I have some questions: > > 1) Compared to method 2, what's the advantage of creating a new vhost char > device? I guess it's for keep the API compatibility? One benefit is that we can avoid doing vhost ioctls on VFIO device fd. > > 2)...

..._core.c index 8b3130f22b42..9e03d158f411 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1478,6 +1478,8 @@ module_init(remoteproc_init); static void __exit remoteproc_exit(void) { + ida_destroy(&rproc_dev_index); + rproc_exit_debugfs(); } module_exit(remoteproc_exit); -- 2.5.0

...o.c index b1877d73fa56..7062bb0975a5 100644 --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -412,6 +412,7 @@ static int virtio_init(void) static void __exit virtio_exit(void) { bus_unregister(&virtio_bus); + ida_destroy(&virtio_index_ida); } core_initcall(virtio_init); module_exit(virtio_exit); -- 2.5.0