On Thu, 19 Oct 2006, Giorgos Keramidas wrote:
FWIW, reverting revision 1.199 of kern_conf.c locally fixes the
unkillable xterms, stuck in "devdrn", problem.
With rev 1.199, modules that do destroy_dev() in their d_close() will
hang in "devdrn" state upon device closing. For example, netsmb and snp:
# mount_smbfs -I server //server/share /mnt
Password:
[hang]
# watch
Snoop started.
Enter device name []:^C
[hang]
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.
Before someone teaches these drivers not doing destroy_dev() in their
d_close(), following bandaid can workaround this hanging problem:
Index: sys/netsmb/smb_dev.c
===================================================================
RCS file: /home/ncvs/src/sys/netsmb/smb_dev.c,v
retrieving revision 1.29
diff -u -p -u -r1.29 smb_dev.c
--- sys/netsmb/smb_dev.c 22 Nov 2005 02:15:46 -0000 1.29
+++ sys/netsmb/smb_dev.c 14 Nov 2006 13:49:37 -0000
@@ -175,6 +175,7 @@ nsmb_dev_close(struct cdev *dev, int fla
*/
dev->si_drv1 = NULL;
free(sdp, M_NSMBDEV);
+ dev_relthread(dev); /* XXX dealing with si_threadcount */
destroy_dev(dev);
splx(s);
return 0;
Index: sys/dev/snp/snp.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/snp/snp.c,v
retrieving revision 1.102
diff -u -p -u -r1.102 snp.c
--- sys/dev/snp/snp.c 19 Sep 2005 13:48:45 -0000 1.102
+++ sys/dev/snp/snp.c 14 Nov 2006 13:49:37 -0000
@@ -489,6 +489,7 @@ snpclose(dev, flags, fmt, td)
free(snp->snp_buf, M_SNP);
snp->snp_flags &= ~SNOOP_OPEN;
dev->si_drv1 = NULL;
+ dev_relthread(dev); /* XXX dealing with si_threadcount */
destroy_dev(dev);
return (snp_detach(snp));
On the other hand, si_threadcount could be negative with aforementioned
patch... :(
On 2006-10-19 02:49, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
Maybe it's not related, but all xterm's seem unkillable and blocked
forever in "devdrn" here, in a build from 2006.10.18.15.56.11.
An earlier sync from 2006.10.13.12.45.54 didn't exhibit this behavior,
so I guess there's something mildly buggy with this change?
On 2006-10-15 09:15, Martin Blapp <[EMAIL PROTECTED]> wrote:
Cool, thank you !
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
------------------------------------------------------------------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l [EMAIL PROTECTED]>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
------------------------------------------------------------------
On Fri, 13 Oct 2006, Tor Egge wrote:
tegge 2006-10-13 20:49:24 UTC
FreeBSD src repository
Modified files:
sys/kern kern_conf.c
Log:
Wait for thread count to reach zero in destroy_devl() even when no purge
method is defined, to avoid memory being modified after free.
Temporarily increase refcount in destroy_devl() to avoid a double free
if dev_rel() is called while waiting for thread count to reach zero.
Revision Changes Path
1.199 +6 -0 src/sys/kern/kern_conf.c
--
Cheers,
Tai-hwa Liang
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
