linux-ext4 - [Bug 76261] ext4_da_writepages err -30 after remount ro during shutdown

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-76261-13602-811UeExom8@https.bugzilla.kernel.org/>
Date:	Fri, 16 May 2014 03:49:28 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 76261] ext4_da_writepages err -30 after remount ro during
 shutdown

https://bugzilla.kernel.org/show_bug.cgi?id=76261

--- Comment #6 from Theodore Tso <tytso@....edu> ---
Looking at the Android source code, they already have code to parse and iterate
over /proc/mounts.  So what I'd recommend is that this code (a) try to do a
normal umount, (b) if (a) fails, try to do a remount read/only, then (c) if (a)
(b) fails, call syncfs() to force the file system to write back all of dirty
data.

Then after it has iterated over all of the file systems, it can then try to do
the emergency remount read/only command.

The other thing I'd suggest is that android do a better job requesting that
processes cleanly shutdown, and then after a decent interval, force kill all of
the remaining processes before doing the file system umount code path as
described above.  If the other processes were cleanly shut down, then there
won't be any further disk writes, and it should be possible for the file
systems to be cleanly unmounted, assuming that the last remaining process
chdir's itself to the root directory, and then remounts the root file system
read/only as the final step.

Again, this is what a proper Unix/Linux system would do for a clean shutdown.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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