Date: Thu, 20 Nov 2008 17:47:28 -0500 From: John Baldwin <jhb@freebsd.org> To: "Paul B. Mahol" <onemda@gmail.com> Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 Message-ID: <200811201747.28540.jhb@freebsd.org> In-Reply-To: <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > On 11/19/08, John Baldwin <jhb@freebsd.org> wrote: > > 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 > > > > 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811201747.28540.jhb>