On 22/05/07 21:06, Matthias Kaehlcke wrote:
El Tue, May 22, 2007 at 09:59:01AM -0700 Arjan van de Ven ha dit:
Please provide context when quoting a patch, git grep takes a while...
printk(KERN_INFO "rp_write %d chars...", count);
@@ -1773,7 +1776,7 @@ end:
this code is very very buggy.
more buggy than with the use of a semaphore?
mutex_lock_interruptible() may not get the mutex in case a signal
happens... and yet you unlox the mutex unconditionally!!!
as far as i understand only the thread that locked the mutex can
unlock it (as opposed to semaphores, which can be released by any
thread/process). obviously this doesn't make the code be more
correct. what i don't know is how the kernel behaves when
trying to unlock a mutex the thread doesn't own. another and possibly
more important problem of the code is that in case of being
interrupted by a signal the data that should be protected by the
mutex/semaphore can be accessed/changed by two threads at the same
would the following resolve the problem?
thanks for your comments
No. At least one user of tty_operations/tty_driver's write function
doesn't check the return value so it would never be retried, mutex_lock
should be used instead.
All of the _interruptible and functions that return -ERESTARTSYS should
probably use __must_check...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]