Zitat von Oliver Neukum <oneu...@suse.com>:
Am Donnerstag, den 24.05.2018, 12:59 +0000 schrieb guido@kiener- muenchen.de:Zitat von Oliver Neukum <oneu...@suse.com>: > Am Donnerstag, den 17.05.2018, 19:03 +0200 schrieb Guido Kiener: > > +static int usbtmc488_ioctl_wait_srq(struct usbtmc_file_data *file_data, > > + unsigned int __user *arg) > > +{ > > + struct usbtmc_device_data *data = file_data->data; > > + struct device *dev = &data->intf->dev; > > + int rv; > > + unsigned int timeout; > > + unsigned long expire; > > + > > + if (!data->iin_ep_present) { > > + dev_dbg(dev, "no interrupt endpoint present\n"); > > + return -EFAULT; > > + } > > + > > + if (get_user(timeout, arg)) > > + return -EFAULT; > > + > > + expire = msecs_to_jiffies(timeout); > > + > > + mutex_unlock(&data->io_mutex); > > There is such a thing as threads sharing file descriptors. > That leads to the question what happens to the mutex if this > ioctl() is called multiple times. > > Regards > Oliver Multiple threads can wait with the same or different file descriptors. When an SRQ interrupt occurs, all threads and file descriptors are informed concurrently with wake_up_interruptible_all(&data->waitq); The "_all" is already fixed in 02/12.No, the problem is that you will underflow io->mutex
Don't worry. The function usbtmc488_ioctl_wait_srq is called by usbtmc_ioctl which already locks the mutex. See https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/usb/class/usbtmc.c#L1189 So the mutex is just unlocked here to allow other threads to still communicate with the device. Regards, Guido -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
