On Fri, Aug 22, 2008 at 3:04 PM, David Howells <dhowells@xxxxxxxxxx> wrote: >> I couldn't reproduce your original failure, but I've attempted to fix >> it by reordering the mutex unlock and bprm free and removing the >> extraneous unlock (see attached patch; it boots for me without >> errors). > > Your patch ought to throw up its own lock failure. You've added a > mutex_unlock() call to the execve success path, but you haven't removed one > from install_exec_creds(). Also, this patch is not sufficient as it doesn't > do anything for compat_do_execve(). Ah, right. Thanks for the review anyway :-) I didn't realize the lock should be held across the function call, I will do a bit more research next time :-) It seems to be a bit tricky. It would probably be nice to have somebody else look at it too and verify that it is now indeed correct? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
