kernel/linux.git/drivers/char/xillybus, branch v6.12.80

char: xillybus: Check USB endpoints when probing device

2024-08-16T07:57:56+00:00

Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints. Reported-by: syzbot+eac39cba052f2e750dbe@syzkaller.appspotmail.com Cc: stable Closes: https://lore.kernel.org/all/0000000000001d44a6061f7a54ee@google.com/T/ Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)"). Signed-off-by: Eli Billauer Link: https://lore.kernel.org/r/20240816070200.50695-2-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: Refine workqueue handling

2024-08-16T07:57:50+00:00

As the wakeup work item now runs on a separate workqueue, it needs to be flushed separately along with flushing the device's workqueue. Also, move the destroy_workqueue() call to the end of the exit method, so that deinitialization is done in the opposite order of initialization. Fixes: ccbde4b128ef ("char: xillybus: Don't destroy workqueue from work item running on it") Cc: stable Signed-off-by: Eli Billauer Link: https://lore.kernel.org/r/20240816070200.50695-1-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: Don't destroy workqueue from work item running on it

2024-08-13T08:06:12+00:00

Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. Reported-by: syzbot+91dbdfecdd3287734d8e@syzkaller.appspotmail.com Cc: stable Closes: https://lore.kernel.org/lkml/0000000000000ab25a061e1dfe9f@google.com/ Signed-off-by: Eli Billauer Link: https://lore.kernel.org/r/20240801121126.60183-1-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: Convert to platform remove callback returning void

2024-03-07T21:49:30+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Acked-by: Eli Billauer Link: https://lore.kernel.org/r/20240306175710.82569-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

char: xillybus: make XILLYBUS_OF depend on HAS_IOMEM

2023-08-04T13:39:39+00:00

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let XILLYBUS_OF depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset: ------ ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined! ------ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He Acked-by: Eli Billauer Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20230707135852.24292-3-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: make xillybus_class a static const structure

2023-06-23T08:27:26+00:00

Now that the driver core allows for struct class to be in read-only memory, move the xillybus_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at load time. Cc: Eli Billauer Cc: Arnd Bergmann Suggested-by: Greg Kroah-Hartman Signed-off-by: Ivan Orlov Acked-by: Eli Billauer Link: https://lore.kernel.org/r/20230620143751.578239-18-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

driver core: class: remove module * from class_create()

2023-03-17T14:16:33+00:00

The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

char: xillybus: Fix trivial bug with mutex

2022-11-23T18:44:04+00:00

@unit_mutex protects @unit from being freed, so obviously it should be released after @unit is used, and not before. This is a follow-up to commit 282a4b71816b ("char: xillybus: Prevent use-after-free due to race condition") which ensures, among others, the protection of @private_data after @unit_mutex has been released. Reported-by: Hyunwoo Kim Signed-off-by: Eli Billauer Link: https://lore.kernel.org/r/20221117071825.3942-1-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: Prevent use-after-free due to race condition

2022-11-11T09:32:41+00:00

The driver for XillyUSB devices maintains a kref reference count on each xillyusb_dev structure, which represents a physical device. This reference count reaches zero when the device has been disconnected and there are no open file descriptors that are related to the device. When this occurs, kref_put() calls cleanup_dev(), which clears up the device's data, including the structure itself. However, when xillyusb_open() is called, this reference count becomes tricky: This function needs to obtain the xillyusb_dev structure that relates to the inode's major and minor (as there can be several such). xillybus_find_inode() (which is defined in xillybus_class.c) is called for this purpose. xillybus_find_inode() holds a mutex that is global in xillybus_class.c to protect the list of devices, and releases this mutex before returning. As a result, nothing protects the xillyusb_dev's reference counter from being decremented to zero before xillyusb_open() increments it on its own behalf. Hence the structure can be freed due to a rare race condition. To solve this, a mutex is added. It is locked by xillyusb_open() before the call to xillybus_find_inode() and is released only after the kref counter has been incremented on behalf of the newly opened inode. This protects the kref reference counters of all xillyusb_dev structs from being decremented by xillyusb_disconnect() during this time segment, as the call to kref_put() in this function is done with the same lock held. There is no need to hold the lock on other calls to kref_put(), because if xillybus_find_inode() finds a struct, xillyusb_disconnect() has not made the call to remove it, and hence not made its call to kref_put(), which takes place afterwards. Hence preventing xillyusb_disconnect's call to kref_put() is enough to ensure that the reference doesn't reach zero before it's incremented by xillyusb_open(). It would have been more natural to increment the reference count in xillybus_find_inode() of course, however this function is also called by Xillybus' driver for PCIe / OF, which registers a completely different structure. Therefore, xillybus_find_inode() treats these structures as void pointers, and accordingly can't make any changes. Reported-by: Hyunwoo Kim Suggested-by: Alan Stern Signed-off-by: Eli Billauer Link: https://lore.kernel.org/r/20221030094209.65916-1-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman

char: xillybus: fix a refcount leak in cleanup_dev()

2022-04-24T15:30:45+00:00

usb_get_dev is called in xillyusb_probe. So it is better to call usb_put_dev before xdev is released. Acked-by: Eli Billauer Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220406075703.23464-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman