Skip site navigation (1)Skip section navigation (2)
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-net" 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>