Date: Tue, 11 Jun 2002 10:35:59 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: John Baldwin <jhb@FreeBSD.org> Cc: net@FreeBSD.org, current@FreeBSD.org Subject: Re: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020611103559.A33391@panzer.kdm.org> In-Reply-To: <XFMail.20020611043704.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Jun 11, 2002 at 04:37:04AM -0400 References: <20020609224036.A21143@panzer.kdm.org> <XFMail.20020611043704.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 11, 2002 at 04:37:04 -0400, John Baldwin wrote: > On 10-Jun-2002 Kenneth D. Merry wrote: > > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > > ends up calling vm_map_entry_create(), same problem as above. > > > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls malloc() with M_WAITOK. > > > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls uma_zalloc() with M_WAITOK. > > > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls MALLOC() with M_WAITOK in various places. > > > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > > with M_WAITOK. > > > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > > vm_map_find(), which through several calls calls vm_map_entry_create(). > > > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > > which does a uma_zalloc() with M_WAITOK. > > > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > > ithread_add_handler() through several layers of indirection. > > ithread_add_handler() calls malloc with M_WAITOK. > > ti_attach() doesn't need to hold its lock while doing these things. Don't > actually enable the logical network device until all the setup for it is done. Okay, will do. > > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > > uma_zalloc with M_WAITOK. > > > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > > function), which calls kmem_alloc_pageable(). See number 1 above, same > > problem here with vm_map_entry_create(). > > > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > > gets called, which calls vm_map_entry_create(), which calls > > uma_zalloc() with M_WAITOK. > > > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > > called through a slightly different path from the same root malloc() > > call in jumbo_vm_init(). > > Same as above with regards to ti_attach(). > > > - the bus_setup_intr(), or rather the kthread code in general apparantly > > isn't safe to be called while holding a mutex. This is the cause of the > > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. > > Yes. Thanks! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020611103559.A33391>