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:	Sat, 7 May 2016 13:47:46 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Daeho Jeong <daeho.jeong@...sung.com>
Cc:	"jack@...e.cz" <jack@...e.cz>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	이기태 <kitae87.lee@...sung.com>
Subject: Re: [PATCH] ext4: guarantee already started handles to successfully
 finish while ro remounting

On Sat, May 07, 2016 at 01:05:49PM +0000, Daeho Jeong wrote:
> 
> Actually, we had executed power on/off test repeatedly with 10 Android
> devices for a month. But, during the test, just this problem only happened
> repeatedly, even if it occurred very rarely. So we had concluded that we
> had to fix this problem certainly.
> 
> However, I can see the point now. Android have misused the emergency
> ro-remount and the filesystem crash by emergency ro-remount is not an issue.
> I can understand the purpose of the emergency ro-remount.
> 
> I heard that the next version of Android will do full scan of ext4 filesystems
> using e2fsck every boot-up, so the existing problem will be naturally resolved,
> even if it might not be the right solution.

I've sent an inquiry to contacts I have in the Google Android team, to
make sure they're aware of the potential issues, whether or not it
gets addressed (by accident) in the next version of Android.

Something to consider is that it's not clear (for example) whether or
not some other file system, such as f2fs, will do the right thing with
such a scheme (and what kind of application data loss you might have,
even if the file systrem checker is run at boot-up).  Or if you have a
process which is actively writing to a SD card containing a VFAT file
system at the time of the shutdown, whether or not it will do the
right thing.

So there are some bigger issues that probably need to be considered,
not just with ext4.

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