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-next>] [day] [month] [year] [list]
Message-Id: <FA695DF7-1D78-471A-A527-0079C045AF09@linuxhacker.ru>
Date:	Fri, 11 Dec 2009 01:45:09 -0500
From:	Oleg Drokin <green@...uxhacker.ru>
To:	linux-ext4@...r.kernel.org
Cc:	Alex Zhuravlev <Alex.Zhuravlev@....COM>,
	Andreas Dilger <adilger@....COM>
Subject: Potential data consistency issue with ASYNC_COMMIT feature

Hello!

   I think ext4 ASYNC_COMMIT feature is potentially pretty unsafe 
   when write-back cache is enabled on the device.
   Since no barriers are ever done with this feature even if
   the barriers are enabled, we might end up in the situation
   where we write the journal blocks, then commit block, they 
   hit the device write-back cache, after that actual metadata
   blocks would be allowed to go to disk and eventually they will.

   In the end the device might decide to reorder some of the
   actual metadata updates in front of journal updates and
   if metadata updates will hit the disk and a power or other
   failure occurs after that, we have inconsistent filesystem
   as a result.

   I do not see an easy way to remedy the problem in this case
   other than to insert empty barrier after the commit block
   and wait for it completion, but I think that would negate
   the entire gain from this feature. I wish we actually had
   real ordered writes implemented, not just barrier/FUA
   sent to the device before every ordered buffer.

   Am I missing something?

   Thanks.

Bye,
    Oleg
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ