From: Andrea Arcangeli <andrea@novell.com>
To: Rajesh Venkatasubramanian <vrajesh@umich.edu>
Cc: Hugh Dickins <hugh@veritas.com>,
Stefan Hornburg <kernel@linuxia.de>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: Kernel BUG at mm/prio_tree.c:538
Date: Mon, 20 Sep 2004 17:39:46 +0200 [thread overview]
Message-ID: <20040920153946.GD3858@dualathlon.random> (raw)
In-Reply-To: <Pine.GSO.4.58.0409201053290.13166@lazuli.engin.umich.edu>
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!
next prev parent reply other threads:[~2004-09-20 15:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 8:04 Kernel BUG at mm/prio_tree.c:538 Stefan Hornburg
2004-09-20 12:58 ` Hugh Dickins
2004-09-20 15:14 ` Rajesh Venkatasubramanian
2004-09-20 15:39 ` Andrea Arcangeli [this message]
2004-10-31 23:39 ` [PATCH 1/2] prio_tree: fix prio_tree_expand corner c Rajesh Venkatasubramanian
2004-10-31 23:46 ` [PATCH 2/2] prio_tree: add Documentation/prio_tree.txt Rajesh Venkatasubramanian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040920153946.GD3858@dualathlon.random \
--to=andrea@novell.com \
--cc=hugh@veritas.com \
--cc=kernel@linuxia.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vrajesh@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox