From owner-p4-projects@FreeBSD.ORG Mon Oct 17 19:53:22 2005 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A61F716A422; Mon, 17 Oct 2005 19:53:21 +0000 (GMT) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A1416A423; Mon, 17 Oct 2005 19:53:21 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D4AD43D83; Mon, 17 Oct 2005 19:53:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 17 Oct 2005 16:09:45 -0400 From: John Baldwin To: soc-chenk Date: Mon, 17 Oct 2005 15:15:37 -0400 User-Agent: KMail/1.8.2 References: <200510151546.j9FFk6X1063636@repoman.freebsd.org> In-Reply-To: <200510151546.j9FFk6X1063636@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510171515.38647.jhb@freebsd.org> Cc: Perforce Change Reviews Subject: Re: PERFORCE change 85342 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 19:53:22 -0000 On Saturday 15 October 2005 11:46 am, soc-chenk wrote: > http://perforce.freebsd.org/chv.cgi?CH=85342 > > Change 85342 by soc-chenk@soc-chenk_leavemealone on 2005/10/15 15:45:35 > > device read converted to use msleep instead of condvar > [this seems to prevent daemon-segfaults-in-readdir panics] > Submitted by: soc-chenk Considering that cv_foo and msleep are both just slim wrappers around sleepq_*(), I can't see how this diff would make any difference, unless adding the 'goto again;' is what fixed the bug, in which case you could have kept the cv(9) usage. > > Affected files ... > > .. //depot/projects/soc2005/fuse4bsd2/fuse_module/fuse.c#18 edit > .. //depot/projects/soc2005/fuse4bsd2/fuse_module/fuse.h#9 edit > > Differences ... > > ==== //depot/projects/soc2005/fuse4bsd2/fuse_module/fuse.c#18 (text+ko) > ==== > > @@ -478,7 +478,6 @@ > > /* Setting up fields of mine */ > mtx_init(&data->msg_mtx, "mutex for fuse message list", NULL, MTX_DEF); > - cv_init(&data->msg_cv, "cv to wake up fusedev_read"); > STAILQ_INIT(&data->fmsg_head); > mtx_init(&data->ticket_mtx, "mutex for the fuse ticketer", NULL, > MTX_DEF); > @@ -503,7 +502,6 @@ > > /* Driving off stage all that stuff thrown at device... */ > mtx_destroy(&data->msg_mtx); > - cv_destroy(&data->msg_cv); > mtx_destroy(&data->callback_mtx); > mtx_destroy(&data->ticket_mtx); > > @@ -526,7 +524,7 @@ > DEBUG2G("banning daemon\n"); > mtx_lock(&data->msg_mtx); > data->dataflag |= FDAT_KICK; > - cv_signal(&data->msg_cv); > + wakeup_one(data); > mtx_unlock(&data->msg_mtx); > } > > @@ -693,7 +691,7 @@ > mtx_lock(&tick->data->msg_mtx); > fuse_msgn_push(&tick->msgn); > DEBUG("ring the bell\n"); > - cv_signal(&tick->data->msg_cv); > + wakeup_one(tick->data); > mtx_unlock(&tick->data->msg_mtx); > } > > @@ -1077,6 +1075,7 @@ > fuprintf("fuse device being read on thread %d\n", uio->uio_td->td_tid); > > mtx_lock(&data->msg_mtx); > +again: > if (fdata_kick_get(data)) { > DEBUG("we know early on that reader should be kicked so we don't wait > for news\n"); mtx_unlock(&data->msg_mtx); > @@ -1084,13 +1083,23 @@ > } > > if ( ! (fmsgn = fdata_pop_msg(data))) { > - err = cv_wait_sig(&data->msg_cv, &data->msg_mtx); > + err = msleep(data, &data->msg_mtx, PCATCH, "fu msg", 0); > if (err != 0) { > mtx_unlock(&data->msg_mtx); > return (fdata_kick_get(data) ? ENODEV : err); > } > fmsgn = fdata_pop_msg(data); > } > + if (! fmsgn) { > + /* > + * We can get here if fuse daemon suddenly terminates, > + * eg, by being hit by a SIGKILL > + * -- and some other cases, too, tho not totally clear, when > + * (cv_signal/wakeup_one signals the whole process ?) > + */ > + DEBUG("no message on thread #%d\n", uio->uio_td->td_tid); > + goto again; > + } > mtx_unlock(&data->msg_mtx); > > if (fdata_kick_get(data)) { > @@ -1105,16 +1114,6 @@ > } > return (ENODEV); /* This should make the daemon get off of us */ > } > - if (! fmsgn) { > - /* > - * We can get here if fuse daemon suddenly terminates, > - * eg, by being hit by a SIGKILL > - * -- and some other cases, too, tho not totally clear, when > - * (cv_signal signals the whole process ?) > - */ > - DEBUG("no message on thread #%d\n", uio->uio_td->td_tid); > - return (EINTR); > - } > DEBUG("message got on thread #%d\n", uio->uio_td->td_tid); > > KASSERT(fmsgn->msg_bufdata || fmsgn->msg_bufsize == 0, > > ==== //depot/projects/soc2005/fuse4bsd2/fuse_module/fuse.h#9 (text+ko) ==== > > @@ -90,7 +90,6 @@ > > struct fuse_data { > struct mtx msg_mtx; > - struct cv msg_cv; > STAILQ_HEAD(, fuse_msg_node) fmsg_head; > > struct mtx callback_mtx; -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org