Re: VM locking problem... And doscmd(8)
On 22-Nov-2002 Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2002-11-21 ] [ Subjecte: Re: VM locking problem... And doscmd(8) ] On Thu, 21 Nov 2002, Juli Mallett wrote: I'm getting a giant owned assertion failure in the vm_map code, simply by running doscmd something.exe where something.exe is a self-extracting ZIP file (of BIOS upgrade stuff, FWIW), which leads trivially to tripping over it. I still don't have a good way to get the trace output from the box in question to here, but I've been able to reproduce it every time, so it shouldn't be hard for someone else. I rebuilt my kernel today from CVSup, but hadn't tried before that. For those of us that don't frequently (ever) use doscmd -- can you provide a tarball of the necessary configuration files, executable, etc, somewhere? I don't (ever) either, and am doing this without a config file (as far as I'm aware anyway), and using the following executable: http://people.freebsd.org/~jmallett/boom.exe There is some discussion on IRC, and Maxime is working on a fix. The problem is that if you use a TSS (for /dev/io or some such) then the TSS gets kmem_free()'d in cpu_thread_exit(). However, cpu_thread_exit() is a particularly bad time to be calling kmem_free() as you are holding sched_lock in a critical section w/o any sleep mutexes when it is called. :) The solution I've discussed with Maxime is to create a cpu_thread_dtor() callout called from thread_dtor() (which is called when a thread is free()'d) and to move the kmem_free() of the TSS into that function instead. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM locking problem... And doscmd(8)
John Baldwin wrote:
On 22-Nov-2002 Juli Mallett wrote:
* De: Robert Watson [EMAIL PROTECTED] [ Data: 2002-11-21 ]
[ Subjecte: Re: VM locking problem... And doscmd(8) ]
On Thu, 21 Nov 2002, Juli Mallett wrote:
I'm getting a giant owned assertion failure in the vm_map code, simply
by running doscmd something.exe where something.exe is a
self-extracting ZIP file (of BIOS upgrade stuff, FWIW), which leads
trivially to tripping over it. I still don't have a good way to get the
trace output from the box in question to here, but I've been able to
reproduce it every time, so it shouldn't be hard for someone else.
I rebuilt my kernel today from CVSup, but hadn't tried before that.
For those of us that don't frequently (ever) use doscmd -- can you provide
a tarball of the necessary configuration files, executable, etc,
somewhere?
I don't (ever) either, and am doing this without a config file (as far as
I'm aware anyway), and using the following executable:
http://people.freebsd.org/~jmallett/boom.exe
There is some discussion on IRC, and Maxime is working on a fix. The
problem is that if you use a TSS (for /dev/io or some such) then the
TSS gets kmem_free()'d in cpu_thread_exit(). However, cpu_thread_exit()
is a particularly bad time to be calling kmem_free() as you are holding
sched_lock in a critical section w/o any sleep mutexes when it is called.
:) The solution I've discussed with Maxime is to create a
cpu_thread_dtor() callout called from thread_dtor() (which is called when
a thread is free()'d) and to move the kmem_free() of the TSS into
that function instead.
The attached patch fixes it for me. It free()'s the TSS in the new
cpu_thread_dtor() function as John suggested.
Cheers,
Maxime
Index: kern/kern_thread.c
===
RCS file: /space2/ncvs/src/sys/kern/kern_thread.c,v
retrieving revision 1.65
diff -u -p -r1.65 kern_thread.c
--- kern/kern_thread.c 21 Nov 2002 01:22:38 - 1.65
+++ kern/kern_thread.c 22 Nov 2002 16:40:16 -
@@ -115,6 +115,7 @@ thread_dtor(void *mem, int size, void *a
{
struct thread *td;
+ mtx_assert(Giant, MA_OWNED);
td = (struct thread *)mem;
#ifdef INVARIANTS
@@ -137,6 +138,8 @@ thread_dtor(void *mem, int size, void *a
/* NOTREACHED */
}
#endif
+
+ cpu_thread_dtor(td);
}
/*
Index: sys/proc.h
===
RCS file: /space2/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.282
diff -u -p -r1.282 proc.h
--- sys/proc.h 21 Nov 2002 09:14:12 - 1.282
+++ sys/proc.h 22 Nov 2002 16:21:52 -
@@ -905,6 +905,7 @@ voidkse_free(struct kse *ke);
void kse_stash(struct kse *ke);
void cpu_set_upcall(struct thread *td, void *pcb);
void cpu_set_upcall_kse(struct thread *td, struct kse *ke);
+void cpu_thread_dtor(struct thread *);
void cpu_thread_exit(struct thread *);
void cpu_thread_setup(struct thread *td);
void kse_reassign(struct kse *ke);
Index: i386/i386/vm_machdep.c
===
RCS file: /space2/ncvs/src/sys/i386/i386/vm_machdep.c,v
retrieving revision 1.193
diff -u -p -r1.193 vm_machdep.c
--- i386/i386/vm_machdep.c 9 Oct 2002 02:33:35 - 1.193
+++ i386/i386/vm_machdep.c 22 Nov 2002 16:42:51 -
@@ -272,24 +272,32 @@ cpu_thread_exit(struct thread *td)
#ifdef DEV_NPX
npxexit(td);
#endif
+if (pcb-pcb_flags PCB_DBREGS) {
+/*
+ * disable all hardware breakpoints
+ */
+reset_dbregs();
+pcb-pcb_flags = ~PCB_DBREGS;
+}
+}
+
+void
+cpu_thread_dtor(struct thread *td)
+{
+ struct pcb *pcb;
+
+ pcb = td-td_pcb;
if (pcb-pcb_ext != 0) {
/* XXXKSE XXXSMP not SMP SAFE.. what locks do we have? */
/* if (pcb-pcb_ext-ext_refcount-- == 1) ?? */
- /*
-* XXX do we need to move the TSS off the allocated pages
+ /*
+* XXX do we need to move the TSS off the allocated pages
* before freeing them? (not done here)
*/
kmem_free(kernel_map, (vm_offset_t)pcb-pcb_ext,
ctob(IOPAGES + 1));
pcb-pcb_ext = 0;
}
-if (pcb-pcb_flags PCB_DBREGS) {
-/*
- * disable all hardware breakpoints
- */
-reset_dbregs();
-pcb-pcb_flags = ~PCB_DBREGS;
-}
}
void
Index: alpha/alpha/vm_machdep.c
===
RCS file: /space2/ncvs/src/sys/alpha/alpha/vm_machdep.c,v
retrieving revision 1.74
diff -u -p -r1.74 vm_machdep.c
--- alpha/alpha/vm_machdep.c23 Sep 2002 08:04:30 - 1.74
+++ alpha/alpha
Re: VM locking problem... And doscmd(8)
* De: Maxime Henrion [EMAIL PROTECTED] [ Data: 2002-11-22 ] [ Subjecte: Re: VM locking problem... And doscmd(8) ] John Baldwin wrote: On 22-Nov-2002 Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2002-11-21 ] [ Subjecte: Re: VM locking problem... And doscmd(8) ] For those of us that don't frequently (ever) use doscmd -- can you provide a tarball of the necessary configuration files, executable, etc, somewhere? I don't (ever) either, and am doing this without a config file (as far as I'm aware anyway), and using the following executable: http://people.freebsd.org/~jmallett/boom.exe There is some discussion on IRC, and Maxime is working on a fix. The problem is that if you use a TSS (for /dev/io or some such) then the TSS gets kmem_free()'d in cpu_thread_exit(). However, cpu_thread_exit() is a particularly bad time to be calling kmem_free() as you are holding sched_lock in a critical section w/o any sleep mutexes when it is called. :) The solution I've discussed with Maxime is to create a cpu_thread_dtor() callout called from thread_dtor() (which is called when a thread is free()'d) and to move the kmem_free() of the TSS into that function instead. The attached patch fixes it for me. It free()'s the TSS in the new cpu_thread_dtor() function as John suggested. Works great, thanks! juli. -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VM locking problem... And doscmd(8)
I'm getting a giant owned assertion failure in the vm_map code, simply by running doscmd something.exe where something.exe is a self-extracting ZIP file (of BIOS upgrade stuff, FWIW), which leads trivially to tripping over it. I still don't have a good way to get the trace output from the box in question to here, but I've been able to reproduce it every time, so it shouldn't be hard for someone else. I rebuilt my kernel today from CVSup, but hadn't tried before that. Thanks, juli. -- Juli Mallett [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
