This is a relatively simple patch to mark cd9660 MPSAFE and enable shared lookups. The changes to cd9660_lookup() mirror similar changes to ufs_lookup() to use static variables for local data rather than abusing i-node members of the parent directory. I've done some light testing of this, but not super-strenuous. This patch also includes simple locking for the iconv support in the kernel. That locking uses an sx lock to serialize open and close of translator tables and the associated refcount. Actual conversions do not need any locks, however as the mount holds a reference on the table. http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
With this patch I'm unable to kldunload libiconv.ko once it is loaded. And trying to kldunload libiconv.ko will make any next kldload/kldstat/kldunload to fail waiting forever(livelock). Regression were not encountered while only cd9660.ko were kldloaded. BTW: Machine crashed during clean shutdown (with old kernel without this patch) after atapicd where kldloaded and after that used some time and tham kldunloaded. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
-- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
So this is actually due to a bug in the module code. If you have two modules like this: DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); The SI_* constants ensure that foo's module handler is called before bar's module handler for MOD_LOAD. However, we don't enforce a reverse order (bar then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is random and has no relation to the SI_* constants. :( What is happening here is that one of the 'bar' modules in libiconv.ko is getting unloaded after 'foo' gets unloaded and using a destroyed lock (you get a panic if you run with INVARIANTS). -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Yes, I tested it on kernel without ddb and friends. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
So this should now be fixed with this commit. If you could verify that iconv works ok with the latest kern_module.c I would appreciate it. Author: jhb Date: Fri Dec 5 16:47:30 2008 New Revision: 185642 URL: http://svn.freebsd.org/changeset/base/185642 Log: When the SYSINIT() to load a module invokes the MOD_LOAD event successfully, move that module to the head of the associated linker file's list of modules. The end result is that once all the modules are loaded, they are sorted in the reverse of their load order. This causes the kernel linker to invoke the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events that is set by the SI_* paramters to DECLARE_MODULE() are now honored in the same order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD events. MFC after: 1 month -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Yes it works, I tried hard multiple times kldload/kldunload
{libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it,
but without success.
FYI following LORs happened:
lock order reversal:
1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442
2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443
3rd 0xc4322bdc isofs (isofs) @
/usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694
KDB: stack backtrace:
db_trace_self_wrapper(c061bff9,c3b566c0,c04e75e5,4,c0617724,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0617724,c3c91468,c3c93828,c3b5671c,...) at kdb_backtrace+0x29
_witness_debugger(c061ecc6,c4322bdc,c44e75c3,c3c93828,c44e7507,...) at
_witness_debugger+0x25
witness_checkorder(c4322bdc,9,c44e7507,2b6,0,...) at witness_checkorder+0x839
__lockmgr_args(c4322bdc,80000,0,0,0,...) at __lockmgr_args+0x797
cd9660_vget_internal(c3feea00,d000,200000,c3b568a8,0,...) at
cd9660_vget_internal+0x147
cd9660_lookup(c3b569f8,c4322c90,c3b56bb0,c4322c90,c3b56a18,...) at
cd9660_lookup+0x4c1
VOP_CACHEDLOOKUP_APV(c44e8a20,c3b569f8,c3b56bb0,c3b56b9c,c3fd1b00,...)
at VOP_CACHEDLOOKUP_APV+0xa5
vfs_cache_lookup(c3b56a78,c3b56a78,5000104,200000,c4322c90,...) at
vfs_cache_lookup+0xcc
VOP_LOOKUP_APV(c44e8a20,c3b56a78,c06249d7,1ba,c3b56b9c,...) at
VOP_LOOKUP_APV+0xa5
lookup(c3b56b84,c06249d7,dc,bc,c410482c,...) at lookup+0x51e
namei(c3b56b84,c108ba38,c108ba34,c3c5e000,c3b56b2c,...) at namei+0x48b
kern_statat(c442d480,200,ffffff9c,282162f8,0,...) at kern_statat+0x6b
kern_lstat(c442d480,282162f8,0,c3b56c18,0,...) at kern_lstat+0x36
lstat(c442d480,c3b56cf8,8,c061f959,c0647af0,...) at lstat+0x2f
syscall(c3b56d38) at syscall+0x283
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (190, FreeBSD ELF32, lstat), eip = 0x281ac413, esp =
0xbfbfe5ac, ebp = 0xbfbfe638 ---
lock order reversal:
1st 0xc440fbdc ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1207
2nd 0xc440fad0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2179
KDB: stack ...This LOR should be addressed in the latest cd9660 locking patches. -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Oh, why I did not checked new version? Yes that LOR have gone, but when doing "ll -R" first time on /mnt I got following messages from kernel: RRIP without PX field? x ~ 50 times. I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
The RRIP stuff is all done in cd9660_vget_internal() under an exclusive lock. It could be a property of the ISO image. "PX" holds permissions (owner, etc.). Do you get the same messages w/o the patch with the same ISO image / CD? -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
No I do not, but I may try other CDs I have many of them, including FreeBSD one. If it is irrelevant than it should not be displayed. -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
-- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
FreeBSD snapshot CD have same "issue". It doesnt appear always (I mean I do not count vfs cache) maybe disabling SMP -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Ignore that reply. cd9660.ko without patch doesnt have this issue. cd9660.ko with cd9660_mpsafe.patch have this issue, on every CD I tried. -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Ok, I will try to reproduce this locally. -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I searched little for this message and found kern/63446 PR interesting comment: Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus d_fileno, VFS_VGET on this value returns bogus vnode with zeroed attributes. I think that whatever locking is done is done wrong. -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
That issue isn't a locking issue, it's an issue with VOP_READDIR() using a different meaning for i-node numbers than VFS_VGET(), and would happen regardless of any Giant or vnode locking. -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Yes, I know that that issue/PR doesnt have anything to do with locking. But displaying bogus messages and still having functional cd9660 for general use means that something is not correctly locked. -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
There are several bugs related to unloading the atapicd module. * g_wither_geom() race against module unload * return value from g_modevent() is ignored * detaching/unloading is allowed even if the device is in use You could try these patches: http://www.saunalahti.fi/~jh3/patches/atapi-cd-locking+tray-control.diff http://www.saunalahti.fi/~jh3/patches/geom-unload-class-race.diff -- Jaakko _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Works fine for me. With that patches panic doesnt not happen during shutdown, -- Paul _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
