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
"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 anyo
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.
>
> Qu
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 proc
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 g
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
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
>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 indirect
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 ker
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 mail
> 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
>> 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 pot
On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote:
[snip]
> Here is a simpler example.
>
> ---
> #include
> #include
>
> #include
> #include
>
> #define SIZE(32 * 1024 * 1024)
>
> int
> main(void)
> {
> void *p;
> char vec[SIZE / PAGE_SIZE];
>
>
: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 i
detected.
Rahul
> Date: Sun, 28 Feb 99 23:52:57 +1100
> From: Bruce Evans
> 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 lockm
>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
>callt
>
> 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
> tra
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
> gr
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
19 matches
Mail list logo
