June 2018 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

[PATCH v2] staging: pi433: add mutex fixing concurrency issues.
by Hugo Lefeuvre June 13, 2018

June 13, 2018

Add a mutex fixing a potential NULL pointer dereference in the pi433 driver. If pi433_release and pi433_ioctl are concurrently called, pi433_release might set filp->private_data to NULL while pi433_ioctl is still accessing it, leading to NULL pointer dereference. This issue might also affect pi433_write and pi433_read. The newly introduced mutex makes sure that instance data will not be modified simultaneously by pi433_release, pi433_write, pi433_read or pi433_ioctl. The mutex is stored in a newly introduced struct pi433_data, which wraps struct pi433_instance and its mutex. Make filp->private_data point to a struct pi433_data, allowing to acquire the lock before accessing the struct pi433_instance. Signed-off-by: Hugo Lefeuvre <hle(a)owl.eu.com> --- Changes in v2: - Use mutex instead of rw semaphore. - Introduce struct pi433_data in order to allow functions to lock before dereferencing instance pointer. - Make filp->private_data point to a struct pi433_data. - Add missing braces. --- drivers/staging/pi433/pi433_if.c | 77 +++++++++++++++++++++++++------- 1 file changed, 62 insertions(+), 15 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index d1e0ddbc79ce..b56dac27e7f1 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -118,6 +118,11 @@ struct pi433_instance { struct pi433_tx_cfg tx_cfg; }; +struct pi433_data { + struct pi433_instance *instance; + struct mutex instance_lock; /* guards instance removal */ +}; + /*-------------------------------------------------------------------------*/ /* GPIO interrupt handlers */ @@ -769,6 +774,7 @@ pi433_tx_thread(void *data) static ssize_t pi433_read(struct file *filp, char __user *buf, size_t size, loff_t *f_pos) { + struct pi433_data *data; struct pi433_instance *instance; struct pi433_device *device; int bytes_received; @@ -778,13 +784,16 @@ pi433_read(struct file *filp, char __user *buf, size_t size, loff_t *f_pos) if (size > MAX_MSG_SIZE) return -EMSGSIZE; - instance = filp->private_data; + data = filp->private_data; + mutex_lock(&data->instance_lock); + instance = data->instance; device = instance->device; /* just one read request at a time */ mutex_lock(&device->rx_lock); if (device->rx_active) { mutex_unlock(&device->rx_lock); + mutex_unlock(&data->instance_lock); return -EAGAIN; } @@ -804,10 +813,13 @@ pi433_read(struct file *filp, char __user *buf, size_t size, loff_t *f_pos) /* if read was successful copy to user space*/ if (bytes_received > 0) { retval = copy_to_user(buf, device->rx_buffer, bytes_received); - if (retval) + if (retval) { + mutex_unlock(&data->instance_lock); return -EFAULT; + } } + mutex_unlock(&data->instance_lock); return bytes_received; } @@ -815,17 +827,22 @@ static ssize_t pi433_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos) { + struct pi433_data *data; struct pi433_instance *instance; struct pi433_device *device; int retval; unsigned int copied; - instance = filp->private_data; + data = filp->private_data; + mutex_lock(&data->instance_lock); + instance = data->instance; device = instance->device; /* check, whether internal buffer (tx thread) is big enough for requested size */ - if (count > MAX_MSG_SIZE) + if (count > MAX_MSG_SIZE) { + mutex_unlock(&data->instance_lock); return -EMSGSIZE; + } /* write the following sequence into fifo: * - tx_cfg @@ -851,6 +868,7 @@ pi433_write(struct file *filp, const char __user *buf, /* start transfer */ wake_up_interruptible(&device->tx_wait_queue); dev_dbg(device->dev, "write: generated new msg with %d bytes.", copied); + mutex_unlock(&data->instance_lock); return copied; @@ -858,6 +876,7 @@ pi433_write(struct file *filp, const char __user *buf, dev_dbg(device->dev, "write to fifo failed: 0x%x", retval); kfifo_reset(&device->tx_fifo); // TODO: maybe find a solution, not to discard already stored, valid entries mutex_unlock(&device->tx_fifo_lock); + mutex_unlock(&data->instance_lock); return -EAGAIN; } @@ -865,6 +884,7 @@ static long pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int retval = 0; + struct pi433_data *data; struct pi433_instance *instance; struct pi433_device *device; void __user *argp = (void __user *)arg; @@ -873,30 +893,37 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) if (_IOC_TYPE(cmd) != PI433_IOC_MAGIC) return -ENOTTY; - /* TODO? guard against device removal before, or while, - * we issue this ioctl. --> device_get() - */ - instance = filp->private_data; + data = filp->private_data; + mutex_lock(&data->instance_lock); + instance = data->instance; device = instance->device; - if (!device) + if (!device) { + mutex_unlock(&data->instance_lock); return -ESHUTDOWN; + } switch (cmd) { case PI433_IOC_RD_TX_CFG: if (copy_to_user(argp, &instance->tx_cfg, - sizeof(struct pi433_tx_cfg))) + sizeof(struct pi433_tx_cfg))) { + mutex_unlock(&data->instance_lock); return -EFAULT; + } break; case PI433_IOC_WR_TX_CFG: if (copy_from_user(&instance->tx_cfg, argp, - sizeof(struct pi433_tx_cfg))) + sizeof(struct pi433_tx_cfg))) { + mutex_unlock(&data->instance_lock); return -EFAULT; + } break; case PI433_IOC_RD_RX_CFG: if (copy_to_user(argp, &device->rx_cfg, - sizeof(struct pi433_rx_cfg))) + sizeof(struct pi433_rx_cfg))) { + mutex_unlock(&data->instance_lock); return -EFAULT; + } break; case PI433_IOC_WR_RX_CFG: mutex_lock(&device->rx_lock); @@ -904,21 +931,26 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) /* during pendig read request, change of config not allowed */ if (device->rx_active) { mutex_unlock(&device->rx_lock); + mutex_unlock(&data->instance_lock); return -EAGAIN; } if (copy_from_user(&device->rx_cfg, argp, sizeof(struct pi433_rx_cfg))) { mutex_unlock(&device->rx_lock); + mutex_unlock(&data->instance_lock); return -EFAULT; } mutex_unlock(&device->rx_lock); + mutex_unlock(&data->instance_lock); break; default: + mutex_unlock(&data->instance_lock); retval = -EINVAL; } + mutex_unlock(&data->instance_lock); return retval; } @@ -936,6 +968,7 @@ pi433_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) static int pi433_open(struct inode *inode, struct file *filp) { + struct pi433_data *data; struct pi433_device *device; struct pi433_instance *instance; @@ -954,20 +987,30 @@ static int pi433_open(struct inode *inode, struct file *filp) } device->users++; + data = kzalloc(sizeof(*data), GFP_KERNEL); + if (!data) { + kfree(device->rx_buffer); + device->rx_buffer = NULL; + return -ENOMEM; + } + mutex_init(&data->instance_lock); + instance = kzalloc(sizeof(*instance), GFP_KERNEL); if (!instance) { + kfree(data); kfree(device->rx_buffer); device->rx_buffer = NULL; return -ENOMEM; } /* setup instance data*/ + data->instance = instance; instance->device = device; instance->tx_cfg.bit_rate = 4711; // TODO: fill instance->tx_cfg; - /* instance data as context */ - filp->private_data = instance; + /* instance data wrapper as context */ + filp->private_data = data; nonseekable_open(inode, filp); return 0; @@ -975,12 +1018,16 @@ static int pi433_open(struct inode *inode, struct file *filp) static int pi433_release(struct inode *inode, struct file *filp) { + struct pi433_data *data; struct pi433_instance *instance; struct pi433_device *device; - instance = filp->private_data; + data = filp->private_data; + mutex_lock(&data->instance_lock); + instance = data->instance; device = instance->device; kfree(instance); + kfree(data); filp->private_data = NULL; /* last close? */ -- 2.17.1

3 5

[PATCH] staging: pi433: add mutex fixing race condition when accessing tx_cfg
by Hugo Lefeuvre June 13, 2018

June 13, 2018

In the PI433_IOC_WR_TX_CFG case in pi433_ioctl, instance->tx_cfg is modified using copy_from_user(&instance->tx_cfg, argp, sizeof(struct pi433_tx_cfg))) without any kind of synchronization. In the case where two threads would execute this same command concurrently the tx_cfg field might enter in an inconsistent state. Add a mutex making sure that the PI433_IOC_WR_TX_CFG case will never be run by several threads concurrently. Signed-off-by: Hugo Lefeuvre <hle(a)owl.eu.com> --- drivers/staging/pi433/pi433_if.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index d1e0ddbc79ce..94c9d5482f44 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -115,6 +115,7 @@ struct pi433_device { struct pi433_instance { struct pi433_device *device; + struct mutex tx_cfg_lock; /* guards race conditions when updating tx config */ struct pi433_tx_cfg tx_cfg; }; @@ -889,9 +890,13 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) return -EFAULT; break; case PI433_IOC_WR_TX_CFG: + mutex_lock(&instance->tx_cfg_lock); if (copy_from_user(&instance->tx_cfg, argp, - sizeof(struct pi433_tx_cfg))) + sizeof(struct pi433_tx_cfg))) { + mutex_unlock(&instance->tx_cfg_lock); return -EFAULT; + } + mutex_unlock(&instance->tx_cfg_lock); break; case PI433_IOC_RD_RX_CFG: if (copy_to_user(argp, &device->rx_cfg, @@ -966,6 +971,8 @@ static int pi433_open(struct inode *inode, struct file *filp) instance->tx_cfg.bit_rate = 4711; // TODO: fill instance->tx_cfg; + mutex_init(&instance->tx_cfg_lock); + /* instance data as context */ filp->private_data = instance; nonseekable_open(inode, filp); -- 2.17.1

2 2

Main Linux kernel vs Ubuntu kernel
by Subhashini Rao Beerisetty June 11, 2018

June 11, 2018

Hi All, Apologies for the dull questions, I’m noob, need to learn lot more stuff. We’ve a bunch of hardware & test systems, we started this project by opting ubuntu distro 16.04 LTS v4.4 kernel for development of device drivers, test utilities. I’d like to know, what are the differences between the main Linux kernel and the kernel being used by Ubuntu? If I need to upgrade our drivers to latest kernel v4.17, what are the best possible ways? In future, is it possible for us to use the current installed 16.04 LTS by just upgrading the Linux kernel version? Are all the Linux kernel releases are backward compatible? Even Ubuntu distro has LTS, non-LTS, GA, HWE kernels, what’s the difference between these? Which one should be the best choice for development & validating the hardware? Can someone clarify me on this? Thanks

4 5

Userspace starving kernel threads for CPU cycle.
by Àbéjídé Àyodélé June 9, 2018

June 9, 2018

Hi, First time poster here. I have a machine with 80 cores and I had a burst of requesting more cpu period than the available number of CPUs, my guess was that this resulted in starvation for the kernel threads, is my guess plausible or do kernel threads get preference for scheduling. Also pardon my ignorance if my question sounds dumb. Thanks, Abejide Ayodele It always seems impossible until it's done. --Nelson Mandela

2 3

a Linux device driver
by Abu Rasheda June 6, 2018

June 6, 2018

Hello, I am an experienced Linux kernel and driver developer and have some time! I like to develop a driver for Linux open source. Any recommendations what device driver is missing and open source community could benefit from a new driver or enhance some existing driver? Where could I go for such information?

4 6

develoment workflow: how to avoid duplicate work ?
by Hugo Lefeuvre June 6, 2018

June 6, 2018

Hi, I've started to take a look at TODO entries in the staging drivers subtree and found some issues in pi433 I'd like to work on. Before starting to prepare my patch, I tried to check the LKML and the bug tracker to make sure nobody was working on the same issues as me (this driver seems to be pretty actively developed), but couldn't find anything helpful. No mailing list, nobody coordinating, only single patches without relationship. Did I miss something ? Is there a specific place where I can coordinate with the rest of the kernel dev community and make people aware I'm working on this particular issue ? (apart from the bug tracker, which doesn't seem to be very active when it comes to the staging subtree) Thanks ! Regards, Hugo -- Hugo Lefeuvre (hle) | www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

4 16

Re: develoment workflow: how to avoid duplicate work ?
by Valentin Vidic June 4, 2018

June 4, 2018

On Mon, Jun 04, 2018 at 06:27:43AM +0000, Nicholas Mc Guire wrote: > are you using kprobes to get this information or how did you trace > these calls ? could you explain how you did that ? I assume that > would be of interest to others as well not only me. Nothing fancy, just added debug print statements to the release and ioctl methods of the pi433 driver. The ioctl method also has a 5s sleep so it takes some time to execute while the other thread calls close on the same file descriptor. The timing should be as follows: 0s thread1 and thread2 start 0s thread1 calls ioctl 1s thread2 calls close 1s thread2 close returns 5s thread1 ioctl returns Adding a dump_stack() call to both driver methods shows that ioctl is called directly: [236449.534358] [<8010ffd8>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24) [236449.534378] [<8010c240>] (show_stack) from [<807840a4>] (dump_stack+0xd4/0x118) [236449.534413] [<807840a4>] (dump_stack) from [<7f5e5348>] (pi433_ioctl+0x64/0x324 [pi433]) [236449.534457] [<7f5e5348>] (pi433_ioctl [pi433]) from [<8029dbe0>] (do_vfs_ioctl+0xac/0x7c4) [236449.534472] [<8029dbe0>] (do_vfs_ioctl) from [<8029e33c>] (SyS_ioctl+0x44/0x6c) [236449.534488] [<8029e33c>] (SyS_ioctl) from [<80108060>] (ret_fast_syscall+0x0/0x28) while the release gets called from task_work_run: [236454.624185] [<8010ffd8>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24) [236454.624204] [<8010c240>] (show_stack) from [<807840a4>] (dump_stack+0xd4/0x118) [236454.624240] [<807840a4>] (dump_stack) from [<7f5e508c>] (pi433_release+0x48/0xc0 [pi433]) [236454.624270] [<7f5e508c>] (pi433_release [pi433]) from [<8028bab0>] (__fput+0x9c/0x1e8) [236454.624288] [<8028bab0>] (__fput) from [<8028bc6c>] (____fput+0x18/0x1c) [236454.624304] [<8028bc6c>] (____fput) from [<8013bbf8>] (task_work_run+0xbc/0xe0) [236454.624322] [<8013bbf8>] (task_work_run) from [<8010b810>] (do_work_pending+0xcc/0xd0) [236454.624340] [<8010b810>] (do_work_pending) from [<80108094>] (slow_work_pending+0xc/0x20) -- Valentin

2 1

pcie dma transfer
by Christoph Böhmwalder June 4, 2018

June 4, 2018

Hi, I'm not sure how on-topic this is on this list, but I have a question regarding a device driver design issue. For our Bachelor's project my team and I are tasked to optimize an existing hardware solution. The design utilizes an FPGA to accomplish various tasks, including a Triple Speed Ethernet controller that is linked to the CPU via PCI express. Currently the implementation is fairly naive, and the driver just does byte-by-byte reads directly from a FIFO on the FPGA device. This, of course, is quite resource intensive and basically hogs up the CPU completely (leading throughput to peak at around 10 Mbit/s). Our plan to solve this problem is as follows: * Keep a buffer on the FPGA that retains a number of Ethernet packages. * Once a certain threshold is reached (or a period of time, e.g. 5ms, elapses), the buffer is flushed and sent directly to RAM via DMA. * When the buffer is flushed and the data is in RAM and accessible by the CPU, the device raises an interrupt, signalling the CPU to read the data. * In the interrupt handler, we `memcpy` the individual packets to another buffer and hand them to the upper layer in the network stack. Our rationale behind keeping a buffer of packets rather than just transmitting a single packet is to maximize the amount of data send with each PCIe transaction (and in turn minimize the overhead). However, upon reading a relevant LDD chapter [1] (which, admittedly, we should have done in the first place), we found that the authors of the book take a different approach: > The second case comes about when DMA is used asynchronously. This happens, > for example, with data acquisition devices that go on pushing data even if > nobody is reading them. In this case, the driver should maintain a buffer so > that a subsequent read call will return all the accumulated data to user > space. The steps involved in this kind of transfer are slightly different: > 1. The hardware raises an interrupt to announce that new data has arrived. > 2. The interrupt handler allocates a buffer and tells the hardware where to transfer > its data. > 3. The peripheral device writes the data to the buffer and raises another interrupt > when it’s done. > 4. The handler dispatches the new data, wakes any relevant process, and takes care > of housekeeping. > A variant of the asynchronous approach is often seen with network cards. These > cards often expect to see a circular buffer (often called a DMAring buffer) established > in memory shared with the processor; each incoming packet is placed in the > next available buffer in the ring, and an interrupt is signaled. The driver then passes > the network packets to the rest of the kernel and places a new DMA buffer in the > ring. Now, there are some obvious advantages to this method (not the least of which being that it's much easier to implement), but I can't help but feel like it would be a little inefficient. Now here's my question: Is our solution to this problem sane? Do you think it would be viable or that it would create more issues than it would solve? Should we go the LDD route instead and allocate a new buffer everytime an interrupt is raised? Thanks for your help! -- Regards, Christoph [1] https://static.lwn.net/images/pdf/LDD3/ch15.pdf (page 30)

2 2

mount command stuck at synchronize_rcu on a RT patched kernel.
by Mahesh Sivapuram June 4, 2018

June 4, 2018

Hello All, We are facing an issue with 3.10.65 kernel + RT69 patch on a 12core xeon. We are running real time applications (higher priority than kernel threads, requiring the resolution of 1ms or less) on ioslated CPU's which are configured through kernel boot arguments as indicated below. Also, we have offloaded the RCU call backs to other book keeping CPU cores. But when we try to perform some general commands like mount some directory over NFS, the command hangs and never completes till we stop our real time applications. The moment real time applications are stopped, command finishes immediately. When we see the backtrace of the mount command, it waiting for "synchronize_rcu". Since we have already offloaded RCU call backs, we expect nothing to be done on isolcpus except rcuc process on isolcpus waking the offloaded threads on other cores. Can someone help us understand what kernel parameters/config needs to be modified/tuned to achieve the proper behavior of the system ? Thanks in advance. Backtrace: ---------- [root@localhost ~]# ps -eaf | grep mount root 17915 4532 0 19:13 pts/0 00:00:00 umount /bng4 root 17916 17915 0 19:13 pts/0 00:00:00 /sbin/umount.nfs /bng4 root 17962 17945 0 19:14 pts/2 00:00:00 grep --color=auto mount [root@localhost ~]# cat /proc/17916/stack [<ffffffff810612b4>] wait_rcu_gp+0x44/0x50 [<ffffffff810c6ec9>] synchronize_rcu+0x29/0x40 [<ffffffff8126446a>] nfs_free_server+0xea/0x180 [<ffffffff8126e49e>] nfs_kill_super+0x1e/0x30 [<ffffffff8115a4ed>] deactivate_locked_super+0x3d/0x60 [<ffffffff8115ab16>] deactivate_super+0x46/0x60 [<ffffffff811770ef>] mntput_no_expire+0xef/0x150 [<ffffffff81178376>] SyS_umount+0x96/0x3d0 [<ffffffff818cbb46>] system_call_fastpath+0x1a/0x1f [<ffffffffffffffff>] 0xffffffffffffffff [root@localhost ~]# Boot arguments: ---------------- [root@localhost ~]# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10.65-rt69 raid=noautodetect console=tty0,115200 ip=none root=/dev/ram0 ramdisk_size=12582912 rw clock=pit rcu_nocbs=1-8 rcu_nocb_poll isolcpus=1-8 irqaffinity=0 tsc=perfect selinux=0 enforcing=0 intel_iommu=on iommu=pt default_hugepagesz=2M hugepagesz=2M hugepages=4096 nohz_full=1-8 idle=poll noswap pci=pcie_bus_perf pcie_aspm=off [root@localhost ~]# Below is our RCU config while compiling the kernel + rt patch. # RCU Subsystem CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=85 CONFIG_RCU_BOOST_DELAY=500 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_NONE=y # CONFIG_RCU_NOCB_CPU_ZERO is not set # CONFIG_RCU_NOCB_CPU_ALL is not set # RCU Debugging # CONFIG_PROVE_RCU_DELAY is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_CPU_STALL_VERBOSE=y CONFIG_RCU_CPU_STALL_INFO=y # CONFIG_RCU_TRACE is not set Thanks & Regards Mahesh

2 1

[PATCH v3] staging: vboxvideo: Update driver to use drm_dev_register.
by Fabio Rafael da Rosa June 4, 2018

June 4, 2018

The use of load and unload hooks is deprecated. DRM drivers should use drm_dev_alloc|drm_dev_init and drm_dev_register for initialization and publishing. Signed-off-by: Fabio Rafael da Rosa <fdr(a)pid42.net> Reviewed-by: Nicholas Mc Guire <der.herr(a)hofr.at> --- Changes in v2: - Replace drm_dev_unref (also depretated) by drm_dev_put Changes in v3: - Add vbox_driver_unload to pci_remove hook so it can free all driver resources drivers/staging/vboxvideo/TODO | 1 - drivers/staging/vboxvideo/vbox_drv.c | 34 +++++++++++++++++++++++---- drivers/staging/vboxvideo/vbox_drv.h | 2 +- drivers/staging/vboxvideo/vbox_main.c | 2 +- 4 files changed, 32 insertions(+), 7 deletions(-) diff --git a/drivers/staging/vboxvideo/TODO b/drivers/staging/vboxvideo/TODO index bd381d861ab3..468eea856ca6 100644 --- a/drivers/staging/vboxvideo/TODO +++ b/drivers/staging/vboxvideo/TODO @@ -1,6 +1,5 @@ TODO: -Move the driver over to the atomic API --Stop using old load / unload drm_driver hooks -Get a full review from the drm-maintainers on dri-devel done on this driver -Extend this TODO with the results of that review diff --git a/drivers/staging/vboxvideo/vbox_drv.c b/drivers/staging/vboxvideo/vbox_drv.c index e18642e5027e..d34f22e07772 100644 --- a/drivers/staging/vboxvideo/vbox_drv.c +++ b/drivers/staging/vboxvideo/vbox_drv.c @@ -51,14 +51,42 @@ MODULE_DEVICE_TABLE(pci, pciidlist); static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { - return drm_get_pci_dev(pdev, ent, &driver); + struct drm_device *dev = NULL; + int ret = 0; + + dev = drm_dev_alloc(&driver, &pdev->dev); + if (IS_ERR(dev)) { + ret = PTR_ERR(dev); + goto err_drv_alloc; + } + dev->pdev = pdev; + pci_set_drvdata(pdev, dev); + + ret = vbox_driver_load(dev); + if (ret) + goto err_vbox_driver_load; + + ret = drm_dev_register(dev, 0); + if (ret) + goto err_drv_dev_register; + + return ret; + + err_drv_dev_register: + vbox_driver_unload(dev); + err_vbox_driver_load: + drm_dev_put(dev); + err_drv_alloc: + return ret; } static void vbox_pci_remove(struct pci_dev *pdev) { struct drm_device *dev = pci_get_drvdata(pdev); - drm_put_dev(dev); + drm_dev_unregister(dev); + vbox_driver_unload(dev); + drm_dev_put(dev); } static int vbox_drm_freeze(struct drm_device *dev) @@ -227,8 +255,6 @@ static struct drm_driver driver = { DRIVER_PRIME, .dev_priv_size = 0, - .load = vbox_driver_load, - .unload = vbox_driver_unload, .lastclose = vbox_driver_lastclose, .master_set = vbox_master_set, .master_drop = vbox_master_drop, diff --git a/drivers/staging/vboxvideo/vbox_drv.h b/drivers/staging/vboxvideo/vbox_drv.h index eeac4f0cb2c6..594f84272957 100644 --- a/drivers/staging/vboxvideo/vbox_drv.h +++ b/drivers/staging/vboxvideo/vbox_drv.h @@ -126,7 +126,7 @@ struct vbox_private { #undef CURSOR_PIXEL_COUNT #undef CURSOR_DATA_SIZE -int vbox_driver_load(struct drm_device *dev, unsigned long flags); +int vbox_driver_load(struct drm_device *dev); void vbox_driver_unload(struct drm_device *dev); void vbox_driver_lastclose(struct drm_device *dev); diff --git a/drivers/staging/vboxvideo/vbox_main.c b/drivers/staging/vboxvideo/vbox_main.c index 9d2018cd544e..429f6a453619 100644 --- a/drivers/staging/vboxvideo/vbox_main.c +++ b/drivers/staging/vboxvideo/vbox_main.c @@ -350,7 +350,7 @@ static void vbox_hw_fini(struct vbox_private *vbox) pci_iounmap(vbox->dev->pdev, vbox->guest_heap); } -int vbox_driver_load(struct drm_device *dev, unsigned long flags) +int vbox_driver_load(struct drm_device *dev) { struct vbox_private *vbox; int ret = 0; -- 2.17.0

1 0