On Mon, Oct 29, 2012 at 4:19 PM, Jan Kara <jack@xxxxxxx> wrote: > On Wed 24-10-12 16:12:44, Ashish Sangwan wrote: >> During orphan cleanup while doing truncate, if we fail to obtain journal >> handle, the inode for which truncate was called would not be removed from >> both the on-disk and in-memory orphan lists as the call to ext3_orphan_del >> would not be executed. >> >> This would have following consequences: >> a) As the inode is not removed from the on-disk list, truncate would be >> called again for the same inode. Each call would add the inode to the >> in-memory list. This operation would continue endlessly or until truncate >> is succeed. >> >> b) If somehow, after some iterations, truncate is succeed, ext3_orphan_del >> will only remove the inode from in-memory list just 1 time. This will trigger >> j_assert during put super. >> >> This patch handles both the problems. If truncate fails, first in-memory >> list is cleared and than the partition is mounted as read only. >> Failure to obtain journal handle during mount may suggest that journal >> device is corrupted. > Could you really trigger any of the described bugs? Because > ext3_truncate() does take care to remove inode from orphan list even if > starting of a transaction fails (see out_notrans label in ext3_truncate()). Sorry, my bad. Did'nt notice out_notrans tag. Actually, its just ext4 which does not clear orphan list. Please ignore this patch. Thanks, Ashish > Also spitting additional messages should be unnecessary - the error which > caused truncate to fail should have logged the error message and also taken > appropriate action depending on filesystem configuration (i.e., remount fs > read-only, panic the system, or do nothing). > -- 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
