Hi Tao, I've been going over the patch series, and one of the things that I started thinking about was whether we really needed the inline_data flag, strictly speaking. After all, the information will be in the extended attribute space in the inode table, so it's relatively cheap to search the ibody looking for the extended attribute, and then to cache that information in a state flag. That might be a useful thing to do, so I'd welcome your comments about whether you think this would be a good idea. But this brought up a bigger issue, which is the one downside of doing this is the potential locking overhead before fetching the information out of the extended attribute --- and that's when I realized the locking is currently *missing*. At the moment, the VFS layer takes i_mutex before calling the per-filesystem extended attribute functions, and that takes care of the locking. However, the inline data patches call ext4_xattr_ibody_find() and ext4_xattr_ibody_set() directly, and they are not taking the i_mutex first. Hence, we have potential races between the a process setting an userspace extended attribute, or selinux setting a security.* xattr, and the new code which tries reading or writing inline data. Could you take a look at this, please? Many thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
