Date: Fri, 9 Feb 2007 08:43:36 -0500 From: John Baldwin <jhb@freebsd.org> To: Tai-hwa Liang <avatar@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netsmb smb_dev.c Message-ID: <200702090843.37371.jhb@freebsd.org> In-Reply-To: <200702090254.l192sDJs085116@repoman.freebsd.org> References: <200702090254.l192sDJs085116@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 08 February 2007 21:54, Tai-hwa Liang wrote: > avatar 2007-02-09 02:54:13 UTC > > FreeBSD src repository > > Modified files: > sys/netsmb smb_dev.c > Log: > It turns out that devfs_close() does a dev_refthread() before invoking > device specific d_close(), which makes subsequent destroy_dev() being > blocked in the "devdrn" loop. > > This bandaid should fix the smbfs hang/crashing observed on -CURRENT since > the introduction of sys/kern/kern_conf.c:1.199: > > # mount_smbfs -I server //server/share /mnt > Password: > [hang] > > Reviewed by: bp > See also: http://lists.freebsd.org/pipermail/cvs-src/2006-November/071379.html No, this is the completely wrong fix for this. Defer the destroy_dev() to a taskqueue or some such. Alternatively, try to get kib@ and other devfs folks to really allow this. One possibility is for dev_destroy() to "know" that it is in a close routine (devfs can set a flag) and defer the work to an internal taskqueue in devfs. Another alternative is to "know" and set a different flag indicating a pending destroy, and devfs can really destroy it when the close routine returns. However, manually dinking with the reference count is completely wrong. What happens when devfs tries to drop the reference count when your close routine returns, does it trash memory? I think you should back this change out and work on a more correct fix. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702090843.37371.jhb>