Date: Sat, 18 May 2002 00:30:46 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Alfred Perlstein <bright@mu.org> Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518003046.A36510@panzer.kdm.org> In-Reply-To: <20020518060255.GN20683@elvis.mu.org>; from bright@mu.org on Fri, May 17, 2002 at 11:02:55PM -0700 References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote: > * Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote: > > > > I have released a new set of zero copy sockets patches, against -current > > from today (May 17th, 2002). > > > > The main change is to deal with the vfs_ioopt changes that Alan Cox made in > > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > > > > The patches and the FAQ are available here: > > > > http://people.freebsd.org/~ken/zero_copy/ > > > > Comments, questions and reviews are all welcome! > > jumbo_vm_init() has a bunch of bugs > > first it doesn't work right if called concurrently. > you need to protect the initialization of jumbo_vm_object otherwise > bad things can happen. my suggestion is to store the results of > vm_object_allocate into a temporary, grab the mutex and then check > to see if jumbo_vm_object has been initialized again if it has then > free the object, otherwise store the allocated object into the > global and continue. The problem here is that the mutex needs to be initialized before I can acquire it, and there's going to be a race between checking to see whether it has been initialized and actually initializing it. e.g.: if (!mtx_initialized(&jumbo_mutex)) mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF); mtx_lock(&jumbo_mutex); if (jumbo_vm_object != NULL) { mtx_unlock(&jumbo_mutex); return (1); } /* allocate our object */ jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES); The above would work, I think, if it weren't for the race in the mutex initialization, and assuming I can allocate a vm object while holding the jumbo mutex. Suggestions? > you may not call malloc(9) with M_WAITOK while holding a mutex. Ahh, okay. > entry = jumbo_kmap_inuse.slh_first; > > I'm sure that should use a list macro. Yes, SLIST_FIRST(), thanks. > That's all I see off the bat. :) Looks cool though. Cool, thanks for the feedback! 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?20020518003046.A36510>