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-vosoZMtB0a@https.bugzilla.kernel.org/>
Date:	Fri, 16 May 2014 12:11:39 +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 #10 from Theodore Tso <tytso@....edu> ---
So see my earlier answer.   If this is a normal shutdown, you must use syncfs()
or the normal umount to unmount the file system.   Emergency_remount is
designed for emergencies when it may not be possible to do a blocking
writeback.   You could change emergency_remount to pass in a force value of 0
instead of 1.  However, this will break non-android use cases where the system
administrator really needs the current behaviour in a real emergency.  Worse,
even for the android use case, there may be times when there may be some kind
of I/O error or other malfunction, where a blocking writeblock could stall the
umount process indefinitely.

So the right answer really is to use the algorithm I've outlined in comment #6.

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