lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 Apr 2016 15:08:27 -0700 From: Nikhilesh Reddy <reddyn@...eaurora.org> To: Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org Subject: Emergency remount readonly and EFBIG errors when unlinking files on 3.18 android kernel Hi As you know Android uses emergency remount instead of doing something like "umount -a" in its shutdown/reboot path. https://android.googlesource.com/platform/system/core/+/master/libcutils/android_reboot.c#132 I have seen a strange issue that sometimes occurs when there are a large number of writes to an ext4 file system and an adb reboot is issued ( triggering an emergency remount readonly and a reboot) Teh issue doesnt happen all the writer processes are killed before the emergency remount And on disk we see that one of the files being written to has incorrect ext4_inode->i_blocks_lo ( which is less than the the size of the file by something like 2k) When unlinking this file the vfs inode->iblocks underflows and we end up with EFBIG if EXT4_FEATURE_RO_COMPAT_HUGE_FILE is not enabled in the superblock. Is this a known issue? I am still trying to figure out why we have a incorrect i_blocks_lo on the disk. Running fsck on the partition does fix the issue but i am trying to figure out why this would happen and how to fix it. I would appreciate if you could point me in the right direction and any help you can give me. -- Thanks Nikhilesh Reddy Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists