[PATCH] MPSAFE/LOOKUP_SHARED cd9660
Paul B. Mahol
onemda at gmail.com
Thu Nov 20 15:26:32 PST 2008
On 11/20/08, John Baldwin <jhb at freebsd.org> wrote:
> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote:
>> On 11/19/08, John Baldwin <jhb at 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
>> > the iconv support in the kernel. That locking uses an sx lock to
>> > open and close of translator tables and the associated refcount. Actual
>> > conversions do not need any locks, however as the mount holds a
>> > reference
>> > 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
>> 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
> 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. :(
Exactly, next time I tried it again and it did not livelock.
> 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).
Yes, I tested it on kernel without ddb and friends.
More information about the freebsd-current