Brian Feldman said:
The lock manager isn't bright enough to detect that the process
already holds a read lock when it attempts to get the write lock.
Thus, you get the thrd_sleep instead of a panic.
In short, same bug, different symptoms.
Ahh, makes sense.
Quick question: how
John S. Dyson wrote:
Brian Feldman said:
Quick question: how in the heck did you learn this whole VM system?
Alan has had a history helping on the VM code for quite a while, and
has contributed some really good ideas. Frankly, he appears to
understand the code as well as anyone does.
On Thu, Mar 04, 1999 at 02:40:14AM +0900, Daniel C. Sobral wrote:
And the question is how he managed to. :-)
I graduated from CMU in 1986. While there, I worked part-time
on the Mach project. Later, I used the Mach VM code as infrastructure
for my Ph.D. thesis on automatic data placement
Until you modify the map, an exclusive lock on the map is overkill. Try
using read locks. (See vm_map_lookup.)
In the meantime, I can't see any reason why mincore acquires an
exclusive lock either. (It never modifies the map.) I'm going
to remedy that.
Doesn't it modify the map indirectly vi
On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote:
Doesn't it modify the map indirectly vi subyte()? I think it wants
to prevent modifications, but this is impossible.
Bear with me, I'll have to split some hairs...
We're only interested in whether mincore directly changes the
On Tue, 2 Mar 1999, Alan Cox wrote:
On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote:
Doesn't it modify the map indirectly vi subyte()? I think it wants
to prevent modifications, but this is impossible.
Bear with me, I'll have to split some hairs...
We're only
On Tue, Mar 02, 1999 at 06:16:50PM -0500, Brian Feldman wrote:
Where exactly does thrd_sleep come in, since that's where the program locks
up now? Can't be killed, of course...
The lock manager isn't bright enough to detect that the process
already holds a read lock when it attempts to get
On Tue, 2 Mar 1999, Alan Cox wrote:
On Tue, Mar 02, 1999 at 06:16:50PM -0500, Brian Feldman wrote:
Where exactly does thrd_sleep come in, since that's where the program locks
up now? Can't be killed, of course...
The lock manager isn't bright enough to detect that the process
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
It appears to me the potential
The question is whether there is a way to do the autogrow function if
the map lock is already held.
Allow lock recurse?
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Until you modify the map, an exclusive lock on the map is overkill. Try
using read locks. (See vm_map_lookup.)
In the meantime, I can't see any reason why mincore acquires an
exclusive lock either. (It never modifies the map.) I'm going
to remedy that.
Alan
To Unsubscribe: send
Admittedly detecting deadlock is not trivial in general. But if we are
about to panic because of deadlock, then we have already detected
something. The question now is: Do we crash the whole system, or just
one or two user processes?
Rahul
:Since bugs do happen, deadlock can occur in the
The attached program sometimes causes a lockmgr panic. I do not think is always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
was detected.
Rahul
Date: Sun, 28 Feb 99 23:52:57 +1100
From: Bruce Evans b...@zeta.org.au
To:curr...@freebsd.org, pango...@home.com
Message-Id: 199902281252.xaa24...@godzilla.zeta.org.au
Subject: Re: lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do
this if a
:deadlock was detected.
:
:Rahul
Well, the lockmgr panic with mmap() is something that ought to be
easily fixable ( by whoever did the stack changes ).
There are also deadlock problems when read()ing or write()ing a file-backed
mmap()'d area.
Most of the deadlocks remaining
On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote:
[snip]
Here is a simpler example.
---
#include sys/param.h
#include sys/mman.h
#include err.h
#include stdlib.h
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE /
The attached program sometimes causes a lockmgr panic. I do not think is always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
On Sat, 27 Feb 1999, Jonathan Hanna wrote:
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
19 matches
Mail list logo
