Messages in this thread | | | Date | Wed, 4 Feb 2004 15:40:45 +0000 | From | Christoph Hellwig <> | Subject | Re: kernel BUG under 2.6.1-mm5 |
| |
> good. here is extended version that includes the same fix + some > cleanup. It removes dead code, removes long obsolete attempt to manage > module refcounting, unifies bdev and cdev - they are treated equal now. > > andrew please consider for -mm for testing. > > More cleanup will follow.
-struct bdev_type -{ - dev_t dev; -}; - -struct cdev_type -{ - struct file_operations *ops; - dev_t dev; - unsigned char autogen:1; -};
Okay, this cleanup is nice, but could you separate it from the bugfixes?
+ * TODO it must be called asynchronously due to the fact + * that devfs is initialized relatively late. Proper way + * is to remove module_init from init_devfs_fs and manually + * call it early enough during system init
What about doing this? This lazy initialization scheme always bothere me..
+ /* + * FIXME HACK + * + * make sure that + * d_instantiate always runs under lock + * we release i_sem lock before going to sleep + * + * unfortunately sometimes d_revalidate is called with + * and sometimes without i_sem lock held. The following checks + * attempt to deduce when we need to add (and drop resp.) lock + * here. This relies on current (2.6.2) calling coventions: + * + * lookup_hash is always run under i_sem and is passing NULL + * as nd + * + * open(...,O_CREATE,...) calls _lookup_hash under i_sem + * and sets flags to LOOKUP_OPEN|LOOKUP_CREATE + * + * all other invocations of ->d_revalidate seem to happen + * outside of i_sem + */ + need_lock = nd && + (!(nd->flags & LOOKUP_CREATE) || (nd->flags & LOOKUP_PARENT)); + + if (need_lock) + down(&dir->i_sem);
Yikes! Don't do such hacks, they will stop working sooner or later. I'd rather add i_sem to all calls to ->d_revalidate in a way that punish filesystems not having ->d_revalidate than such a hack
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |