On Mon, 11 Jun 2007, Russell King wrote:
>
> The deadlock involves mmap_sem having been taken by the futex code
> and a page fault occuring in copy_from_user_inatomic(). We then
> hit this:
No, we don't. If you hit that code, you're buggy.
Look at what x86 has just before that sequence:
/*
* If we're in an interrupt, have no user context or are running in an
* atomic region then we must not take the fault..
*/
if (in_atomic() || !mm)
goto bad_area_nosemaphore;
and the whole *point* of "copy_from_user_inatomic()" is that it should
trigger the "in_atomic()" check, and we will never even get to the code
you point at:
> /*
> * As per x86, we may deadlock here. However, since the kernel only
> * validly references user space from well defined areas of the code,
> * we can bug out early if this is from code which shouldn't.
> */
> if (!down_read_trylock(&mm->mmap_sem)) {
And as far as I can see, arm has the same "in_acomit()" checks too.
Maybe the arm implementation of in_atomic() or copy_from_user_inatomic()
is broken some way?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
