| 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
| ||
|
Message-ID: <20110406134428.GA17705@infradead.org> Date: Wed, 6 Apr 2011 09:44:28 -0400 From: Christoph Hellwig <hch@...radead.org> To: Dave Chinner <david@...morbit.com> Cc: Jan Kara <jack@...e.cz>, Toshiyuki Okajima <toshi.okajima@...fujitsu.com>, Ted Ts'o <tytso@....edu>, Masayoshi MIZUMA <m.mizuma@...fujitsu.com>, Andreas Dilger <adilger.kernel@...ger.ca>, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock On Wed, Apr 06, 2011 at 09:21:35PM +1000, Dave Chinner wrote: > Sure, but the question must be asked - why is ext3/4 even starting a > transaction on a clean filesystem during sync? A frozen filesystem, > by definition, is a clean filesytem, and therefore sync calls of any > kind should not be trying to write to the FS or start transactions. > XFS does this just fine, so I'd consider such behaviour on a frozen > filesystem a bug in ext3/4... XFS does have one special case for this. When writing the dummy log record at the end of the freeze process we use _xfs_alloc_trans to bypass the frozen filesystem check as we have to write out this record when the filesystem already is frozen. But that's after the main sync with its normal transactions. -- 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