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

Powered by blists - more mailing lists