2008/5/20 Matthew Wilcox <matthew@xxxxxx>: > On Tue, May 20, 2008 at 04:18:14PM +0100, Tom Spink wrote: >> + >> + mutex_lock(&type->fs_supers_lock); >> + if (list_empty(&type->fs_supers) && type->init) { >> + err = type->init(); >> + if (err) { >> + mutex_unlock(&type->fs_supers_lock); >> + spin_unlock(&sb_lock); >> + destroy_super(s); >> + return ERR_PTR(err); >> + } >> + } >> + >> + list_add(&s->s_instances, &type->fs_supers); >> + mutex_unlock(&type->fs_supers_lock); >> + >> s->s_type = type; >> strlcpy(s->s_id, type->name, sizeof(s->s_id)); >> list_add_tail(&s->s_list, &super_blocks); >> - list_add(&s->s_instances, &type->fs_supers); >> + >> spin_unlock(&sb_lock); > > You can't take a mutex while holding a spinlock -- what if you had to > sleep to acquire the mutex? > > I imagine you also don't want to hold a spinlock while calling the > ->init or ->exit -- what if the fs wants to sleep in there (eg allocate > memory with GFP_KERNEL). > > -- > Intel are signing my paycheques ... these opinions are still mine > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." > Oh no! This is bad. I really need to devise some script to stress test my code - and also make myself pay attention to what I'm doing. Sorry for the noise, guys. -- Tom Spink -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html