lkml.org 
[lkml]   [2004]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.071 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site