![]() | |||||||||||||
Messages in this thread |
Hi Matthias, On 4/25/07, Robert Hancock <hancockr@shaw.ca> wrote: > Matthias Kaehlcke wrote: > > El Tue, Apr 24, 2007 at 07:53:04PM +0200 Oliver Neukum ha dit: > > > >> Am Dienstag, 24. April 2007 19:49 schrieb Matthias Kaehlcke: > >>> @@ -1706,7 +1706,7 @@ static int rp_write(struct tty_struct *tty, > >>> if (count <= 0 || rocket_paranoia_check(info, "rp_write")) > >>> return 0; > >>> > >>> - down_interruptible(&info->write_sem); > >>> + mutex_lock_interruptible(&info->write_mtx); > >> This is a bug. It is also present in the current code, but nevertheless > >> it is a bug. If you use an interruptible lock, you must be ready to deal > >> with interrupts, which are ignored by this code. > > [...] > > i'm a bit confused now about the interruptible locks, i thought using > > them means that the process will be waked up when receiving a > > signal. what role are playing interrupts when using interruptible locks? > > You are correct, interrupts aren't involved. However if the wait is > interrupted by a signal, mutex_lock_interruptible will return a nonzero > return code which needs to be checked for (and likely -ERESTARTSYS or > -EINTR returned), otherwise the code will blindly continue as though it > has locked the mutex even though it has not. Think I'll elaborate Robert's explanation for your benefit :-) Unlike mutex_lock() and down() that put the task to TASK_UNINTERRUPTIBLE sleep if the lock can't be acquired immediately, mutex_lock_interruptible() and down_interruptible() sleep in TASK_INTERRUPTIBLE state. So the task _can_ be woken up (without even acquiring the lock) by incoming signals. When that happens, we can't just blindly go on ... so the return values of the _interruptible() versions of the locking functions *must* be checked for success and if not, the task should return with error. Use -ERESTARTSYS if a previous intermediate caller checks this return value and tries and restarts the whole operation. If no such previous caller exists (and/or introducing it would involve a change in kernel behaviour as seen from userspace), you can safely use -EINTR. The goal is that userspace must not get to see -ERESTARTSYS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-04-25 05:09 [W:0.321 / U:0.050 seconds] ©2003-2008 Jasper Spaans | |||||||||||||