Not that, I hope. Possibly it's the interaction between
block_write_full_pages's memset outside i_size, truncate and lookup.
It took me a ridiculous amount of time to get that "correct", so
it's a suspicion point. Or possibly locking between lookup and
truncate (rmdir) and/or creat.
Dave, I assume this is with 8k pages and 4k blocks?
Is it repeatable enough to conduct a little experiment? Like, lock the page
in ext2_find_entry?
--- linux-2.5.22/fs/ext2/dir.c Wed May 29 11:42:43 2002
+++ 25/fs/ext2/dir.c Mon Jun 17 20:50:48 2002
@@ -348,6 +348,7 @@ struct ext2_dir_entry_2 * ext2_find_entr
char *kaddr;
page = ext2_get_page(dir, n);
if (!IS_ERR(page)) {
+ lock_page(page);
kaddr = page_address(page);
de = (ext2_dirent *) kaddr;
kaddr += ext2_last_byte(dir, n) - reclen;
@@ -355,6 +356,7 @@ struct ext2_dir_entry_2 * ext2_find_entr
if (de->rec_len == 0) {
ext2_error(dir->i_sb, __FUNCTION__,
"zero-length directory entry");
+ unlock_page(page);
ext2_put_page(page);
goto out;
}
@@ -367,10 +369,12 @@ struct ext2_dir_entry_2 * ext2_find_entr
if (++n >= npages)
n = 0;
} while (n != start);
+ unlock_page(page);
out:
return NULL;
found:
+ unlock_page(page);
*res_page = page;
ei->i_dir_start_lookup = n;
return de;
-
-
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/