Re: Kernel BUG at mm/prio_tree.c:538

Andrea Arcangeli
2004-09-20T15:39:55Z

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!