From owner-freebsd-current Tue Jun 11 1:37:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id 5A33337B40B for ; Tue, 11 Jun 2002 01:37:14 -0700 (PDT) Received: (qmail 9855 invoked from network); 11 Jun 2002 08:37:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2002 08:37:12 -0000 Received: from laptop.baldwin.cx ([206.187.69.211]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g5B8bAQ81411; Tue, 11 Jun 2002 04:37:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020609224036.A21143@panzer.kdm.org> Date: Tue, 11 Jun 2002 04:37:04 -0400 (EDT) From: John Baldwin To: "Kenneth D. Merry" Subject: RE: new zero copy sockets snapshot, WITNESS problems Cc: net@FreeBSD.org, current@FreeBSD.org 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 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. > 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message