We never walk the list - the only reason for it is to make the resource fork
inodes appear hashed to the writeback code. Borrow a trick from JFS to do
that without needing a list head.
Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxx>
Index: linux-2.6/fs/hfsplus/hfsplus_fs.h
===================================================================
--- linux-2.6.orig/fs/hfsplus/hfsplus_fs.h 2010-09-30 10:28:22.292782389 +0200
+++ linux-2.6/fs/hfsplus/hfsplus_fs.h 2010-09-30 10:28:30.424782609 +0200
@@ -145,8 +145,6 @@ struct hfsplus_sb_info {
int part, session;
unsigned long flags;
-
- struct hlist_head rsrc_inodes;
};
#define HFSPLUS_SB_WRITEBACKUP 0x0001
Index: linux-2.6/fs/hfsplus/inode.c
===================================================================
--- linux-2.6.orig/fs/hfsplus/inode.c 2010-09-30 10:28:39.452782662 +0200
+++ linux-2.6/fs/hfsplus/inode.c 2010-09-30 10:29:46.485782660 +0200
@@ -204,7 +204,15 @@ static struct dentry *hfsplus_file_looku
hip->rsrc_inode = dir;
HFSPLUS_I(dir)->rsrc_inode = inode;
igrab(dir);
- hlist_add_head(&inode->i_hash, &HFSPLUS_SB(sb)->rsrc_inodes);
+
+ /*
+ * __mark_inode_dirty expects inodes to be hashed. Since we don't
+ * want resource fork inodes in the regular inode space, we make them
+ * appear hashed, but do not put on any lists. hlist_del()
+ * will work fine and require no locking.
+ */
+ inode->i_hash.pprev = &inode->i_hash.next;
+
mark_inode_dirty(inode);
out:
d_add(dentry, inode);
Index: linux-2.6/fs/hfsplus/super.c
===================================================================
--- linux-2.6.orig/fs/hfsplus/super.c 2010-09-30 10:29:54.519782662 +0200
+++ linux-2.6/fs/hfsplus/super.c 2010-09-30 10:29:59.077782662 +0200
@@ -321,7 +321,6 @@ static int hfsplus_fill_super(struct sup
return -ENOMEM;
sb->s_fs_info = sbi;
- INIT_HLIST_HEAD(&sbi->rsrc_inodes);
mutex_init(&sbi->alloc_mutex);
hfsplus_fill_defaults(sbi);
if (!hfsplus_parse_options(data, sbi)) {
--
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
