linux-ext4 - Re: Emergency remount readonly and EFBIG errors when unlinking files on 3.18 android kernel

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 27 Apr 2016 10:56:35 -0700
From:	Nikhilesh Reddy <reddyn@...eaurora.org>
To:	Theodore Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Emergency remount readonly and EFBIG errors when unlinking files
 on 3.18 android kernel

Hi

Thanks for your reply
Yes the sentence below should have the *if* .. sorry about the typo
The issue doesnt happen if all the writer processes/threads are killed 
before the
emergency remount

>
> Note that an emergency remount is very much an emergency.  So we don't
> do a graceful shutdown of any pending writes.  (Normally we would
> return EBUSY if there anything that would prevent a clean remount.)
> In the emergency remount path, we bypass all of these checks.
>
>> 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?
>
> No, this isn't a known issue.  I've never seen anything like this, but
> all of the tests we do assume a forced poweroff, which we simulate
> using dm-flakey.  We do *not* test the blunt-force-trauma which is
> inflected on the file system structures which results from doing an
> emergency remount.
>
> Off by 2k really doesn't make sense.  I could see if it was off by 4k,
> but 2k is really wierd.

Just to clarify when i say off by 2k .. i meant the i_blocks count not 
the actual size file ( which would be 2k * 512 if i am not wrong)

For example we see fsck report
Pass 1: Checking inodes, blocks, and sizes
Inode XXX, i_blocks is 854024, should be 856072.

>
>> I would appreciate if you could point me in the right direction and any help
>> you can give me.
>
> Well, what I'd do is create a new ioctl interface which simulates an
> emergency ro on just the one device, and try to create a reliable
> repro.  Eventually we'll want to add some tests for this in xfstests.
>

Thanks so much for your suggestion.
I will try to see if i can reliably reproduce the issue after 
implementing the ioctl as you suggested.
I have some issues getting the xfs tests to run on the device which i 
have been meaning to work on .. maybe this is the time to do so.


-- 
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