From owner-freebsd-current Tue Jun 11 9:36: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0E70C37B40F; Tue, 11 Jun 2002 09:36:00 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5BGZxQ33413; Tue, 11 Jun 2002 10:35:59 -0600 (MDT) (envelope-from ken) Date: Tue, 11 Jun 2002 10:35:59 -0600 From: "Kenneth D. Merry" To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org Subject: Re: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020611103559.A33391@panzer.kdm.org> References: <20020609224036.A21143@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Jun 11, 2002 at 04:37:04AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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