lkml.org 
[lkml]   [2004]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.055 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site