Please learn how to trim emails down to contain only the bits relevant to your reply, thanks.
On Tue, Feb 18, 2014 at 03:25:21PM +0100, Marek Szyprowski wrote:
Hello,
On 2014-02-12 17:33, Russell King - ARM Linux wrote:
So, the full locking dependency tree is this:
CPU0 CPU1 CPU2 CPU3 CPU4 dev->struct_mutex (from #0) mm->mmap_sem dev->struct_mutex (from #5) console_lock (from #4) mm->mmap_sem cpu_hotplug.lock (from #3) console_lock cma_mutex (from #2, but also from #1) cpu_hotplug.lock cma_mutex
Which is pretty sick - and I don't think that blaming this solely on V4L2 nor DRM is particularly fair. I believe the onus is on every author of one of those locks involved in that chain needs to re-analyse whether their locking is sane.
For instance, what is cma_mutex protecting? Is it protecting the CMA bitmap?
This lock is protecting CMA bitmap and also serializes all CMA allocations. It is required by memory management core to serialize all calls to alloc_contig_range() (otherwise page block's migrate types might get overwritten). I don't see any other obvious solution for serializing alloc_contig_range() calls.
That's unfortunate, because what you're effectively asking is for every subsystem in the kernel to avoid a complex set of lock dependencies. It appears that two subsystems have now hit this, and I wouldn't be surprised if they weren't the last.
This will not work correctly if there will be 2 concurrent calls to alloc_contig_range(), which will touch the same memory page blocks.
Can you see any other way to lessen the impact of cma_mutex on the whole kernel?