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
| ||
|
Date: Thu, 31 Mar 2011 16:48:39 +0800 From: Yongqiang Yang <xiaoqiangnk@...il.com> To: Jan Kara <jack@...e.cz>, Amir Goldstein <amir73il@...il.com> Cc: 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 Thu, Mar 31, 2011 at 4:37 PM, Yongqiang Yang <xiaoqiangnk@...il.com> wrote: > Hi everyone, > > Amir met a deadlock when he tested ext4 with snapshot. The deadlock > was reported on > https://github.com/amir73il/ext4-snapshots/commit/56396185d922a73524a091b545e665543abf741a. > It is difficult to reproduce the deadlock. There is a deadlock > reported on http://www.spinics.net/lists/linux-ext4/msg23018.html. > Actually, these two deadlocks come from a same source. > > Below are my analysis on the 1st one. Mail is not a good place to > describe parallel processes. I have submitted the analysis to > https://github.com/YANGYongqiang/ext4-snapshots/blob/9e0ae9ae9907125e6bf45aa91db296d4cc041b17/fs/ext4/BUGS#L143. > It is much more readable. > > -- deadlock in ext4 with snapshot > ext4 with snapshot calls freeze_super() to bring > a fs be in a clean state when a user takes a snapshot. > > freeze truncate kjournald > > | ext4_ext_truncate | > freeze_super() | starts a handle | > sets s_frozen | | > | ext4_ext_truncate | > | holds i_data_sem | > ext4_freeze() | | commit_transaction() > wait for updates | | waits for i_data_sem > | ext4_free_blocks | > | calls dquot_free_block| > | | > | dquot_free_block call | > | ext4_dirty_inode | > | | > | ext4_dirty_inode | > | trys to start a handle| > | | > | block due to s_frozen | > > in ext3, ext3_freeze() prevents journal from being updated by > lock_journal_updates(), ext3_unfreeze() allow journal to be updated by > unlock_journal_updates(). > > in ext4, however, before ext4_freeze() returns, it unlock journal, and > ext4 prevents journal from being updated by s_frozen. s_frozen is in > an upper layer, so it is out control of ext4 and deadlock is easy to > happen. Virtually, it is not right to block ext4_journal_start_sb() before we confirm that current thread has no a active handle. But ext4 does like that. Deadlock is thus easy to happen. Right? > > Could someone explain why ext4 does like above but not follow ext3? > > Yongqiang. > -- > Best Wishes > Yongqiang Yang > -- Best Wishes Yongqiang Yang -- 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