Date: Thu, 23 Sep 2010 17:02:13 -0400 From: John Baldwin <jhb@freebsd.org> To: "Ricky Charlet" <RCharlet@adaranet.com> Cc: "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org> Subject: Re: newbie trouble with destroy_dev Message-ID: <201009231702.13158.jhb@freebsd.org> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C950492@SJ-EXCH-1.adaranet.com> References: <32AB5C9615CC494997D9ABB1DB12783C024C95033B@SJ-EXCH-1.adaranet.com> <201009230949.12884.jhb@freebsd.org> <32AB5C9615CC494997D9ABB1DB12783C024C950492@SJ-EXCH-1.adaranet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, September 23, 2010 1:42:33 pm Ricky Charlet wrote: > Thanks. > That totally worked. Lesson learned = destroy_dev sooner than destroy cv's and mutexes's and internal state. > > One question though... I did not find any "DYING" flag in relation to cv's or mutexes. So I just skipped that step in your advice. I only found the string "DYING" in relation to jails, sound-drivers, some network stuff and ipsec. Will you give me a little more specific pointer to what "DYING" flag you were referring to? I meant a flag specific to your driver. Basically a way for the code you are sending the cv_broadcast to to know they should break out of whatever loop they are in, etc. > FYI, my userland program sitting in the read loop exited cleanly and got errno=ENXIO, which is beautiful. > > Thanks again. > > --- > Ricky Charlet > Adara Networks > USA 408-433-4942 > > > > > -----Original Message----- > From: John Baldwin [mailto:jhb@freebsd.org] > Sent: Thursday, September 23, 2010 6:49 AM > To: freebsd-drivers@freebsd.org > Cc: Ricky Charlet > Subject: Re: newbie trouble with destroy_dev > > On Wednesday, September 22, 2010 3:11:10 pm Ricky Charlet wrote: > > Howdy, > > > > My goal is to destroy a character device which is currently > open for read. Is that allowable? I'm hoping the userland program doing the > reading will simply get a read error back (possibly with no data or truncated > data). > > > > My experience so far is that I crash the box. > > > > I'm using BSD 8.0. My program with the driver is a kernel > module. Upon using the `kldunload` utility, the d_close() method is called. I > have tried these logic flows: > > > > Test 1 > > --------------------- > > Unhook my packet-filter-hooks > > cv_broadcast; > > cv_destory > > mMtx_destroy > > destroy_dev > > free associated buffers > > > > Test 2 > > -------------------- > > Unhook my packet-filter-hooks > > cv_broadcast; > > cv_destory > > mMtx_destroy > > destroy_dev_sched_cb > > free associated buffers > > > > Test 3 > > ---------------------- > > Unhook my packet-filter-hooks > > cv_broadcast; > > cv_destory > > mMtx_destroy > > free associated buffers > > > > > > In all cases I get a kernel crash and the system reboots. > Note that the userland program has the associated charater device open and is > in a for-ever loop reading the fd. > > > > I'm a newbie and have not yet attached a debugger. I'll go > start reading about that and trying it out while I hopefully await replies. > > Call destroy_dev() earlier, before you destroy any state. Your cdevsw > routines can be invoked right up until destroy_dev() returns, so if you > destroy the mutex before destroy_dev() you might destroy it before a cdevsw > routine tries to use it. I suspect you might need something like: > > unhook_packet_filters > set DYING flag (for listeners to the cv to know to exit, etc.) > cv_broadcast() > destroy_dev() > free buffers > cv_destroy() > mtx_destroy() > > -- > John Baldwin > -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009231702.13158.jhb>