Messages in this thread | | | Date | Mon, 20 Sep 2004 17:39:46 +0200 | From | Andrea Arcangeli <> | Subject | Re: Kernel BUG at mm/prio_tree.c:538 |
| |
On Mon, Sep 20, 2004 at 11:14:53AM -0400, Rajesh Venkatasubramanian wrote: > The only chance I see for this to happen: we are changing vm_start, > vm_end, vm_pgoff of a vma that is already in an i_mmap tree > without holding the corresponding i_mmap_lock. The last time I > did an audit, all such changes were inside the i_mmap_lock.
they should yes. Only the anon_vma_lock can be dropped before vm_end modifications (but only for vm_end, vm_start and vm_pgoff updates still needs the anon_vma_lock hold to be coherent with vm_pgoff reads).
operations on memory-seeking data structures like lists and trees tends to be the most likely to show bad ram, we had it for some time in the dcache layer for the dcache shrinking (still todate AFIK they were all hardware issues), this could be a similar case.
though I agree the same BUG_ON triggering worth a second check.
Thanks a lot! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |