> Hmm, I'm not really comfortable with putting this hack in, since this
> is papering over the real problem, which is that Android is trying to
> use the emergency remount read-only sysrq option and this is
> fundamentally unsafe. I'm not sure what else could break if it is
> situation normal that there is active processes busily writing to the
> file system and sysrq-u followed by reboot is the normal way the
> Android kernel does a reboot.
> A much better solution would be to change the Android userspace to
> call the FIFREEZE ioctl on each mounted file system, and then call for
> a reboot.
I agree with you. I know that current Android shutdown procedure is
not a safe way. But, without this patch, "even not in Android system",
when we trigger the emergency read-only remount while evicting inodes,
i_size of the inode becomes zero and the inode is not in orphan list,
but blocks of the inode are still allocated to the inode, because
ext4_truncate() will fail while stating the handle which was already started
by ext4_evict_inode(). This causes the filesystem inconsistency and
we will encounter an ext4 kernel panic in the next boot by this problem.
I think that this kind of filesystem crash can occur anywhere that
the same journal handle is repeatly used. During an atomic filesystem
operation, a part of the operation will succeed and the other one will fail.
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
