[PATCH 4/4] Do not call flush_cache_user_range with mmap_sem held

[catalin.marinas@arm.com (Catalin Marinas)]

On Fri, Aug 26, 2011 at 08:32:28AM +0100, Jiejing.Zhang  wrote:
> I met this issue on our development board: iMX53 + 2.6.35.2 Kernel,
> this is stack trace when the dead lock happens.
> 
> You can see the hung task are dead lock at __read_lock(), after I add
> more debug message and dump the hung task's stack trace.
> 
> After apply this patch, the hung is gong.

Russell doesn't agree with the original patch, so we have to live with
this dead-lock in mainline :(. From my perspective, it is a perfectly
valid patch and there is no race. I'll keep it in my trees for now.

If a user space app is so badly written that it calls the cache flushing
function while remapping the same memory range from a different thread,
it deserve some failures. But even then, the cache flushing function is
simply cleaning the D-cache which is a safe operation (as compared to
invalidation).

For reference, that's the original post:

http://article.gmane.org/gmane.linux.ports.arm.kernel/99356

-- 
Catalin