linux-kernel - [PATCH 00/19] Fix filesystem freezing deadlocks

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: <1330963277-26336-1-git-send-email-jack@suse.cz>
Date:	Mon,  5 Mar 2012 17:00:58 +0100
From:	Jan Kara <jack@...e.cz>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	linux-fsdevel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>, dchinner@...hat.com,
	sandeen@...hat.com, Kamal Mostafa <kamal@...onical.com>,
	Jan Kara <jack@...e.cz>, Alex Elder <elder@...nel.org>,
	Anton Altaparmakov <anton@...era.com>, Ben Myers <bpm@....com>,
	Chris Mason <chris.mason@...cle.com>, cluster-devel@...hat.com,
	"David S. Miller" <davem@...emloft.net>,
	fuse-devel@...ts.sourceforge.net,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Joel Becker <jlbec@...lplan.org>,
	KONISHI Ryusuke <konishi.ryusuke@....ntt.co.jp>,
	linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org,
	linux-ntfs-dev@...ts.sourceforge.net,
	Mark Fasheh <mfasheh@...e.com>,
	Miklos Szeredi <miklos@...redi.hu>, ocfs2-devel@....oracle.com,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Steven Whitehouse <swhiteho@...hat.com>,
	"Theodore Ts'o" <tytso@....edu>, xfs@....sgi.com
Subject: [PATCH 00/19] Fix filesystem freezing deadlocks

  Hallelujah,

  after a couple of weeks and several rewrites, here comes the third iteration
of my patches to improve filesystem freezing.  Filesystem freezing is currently
racy and thus we can end up with dirty data on frozen filesystem (see changelog
patch 06 for detailed race description). This patch series aims at fixing this.

To be able to block all places where inodes get dirtied, I've moved filesystem
freeze handling in mnt_want_write() / mnt_drop_write(). This however required
some code shuffling and changes to kern_path_create() (see patches 02-05). I
think the result is OK but opinions may differ ;). The advantage of this change
also is that all filesystems get freeze protection almost for free - even ext2
can handle freezing well now.

Another potential contention point might be patch 19. In that patch we make
freeze_super() refuse to freeze the filesystem when there are open but unlinked
files which may be impractical in some cases. The main reason for this is the
problem with handling of file deletion from fput() called with mmap_sem held
(e.g. from munmap(2)), and then there's the fact that we cannot really force
such filesystem into a consistent state... But if people think that freezing
with open but unlinked files should happen, then I have some possible
solutions in mind (maybe as a separate patchset since this is large enough).

I'm not able to hit any deadlocks, lockdep warnings, or dirty data on frozen
filesystem despite beating it with fsstress and bash-shared-mapping while
freezing and unfreezing for several hours (using ext4 and xfs) so I'm
reasonably confident this could finally be the right solution.

And for people wanting to test - this patchset is based on patch series
"Push file_update_time() into .page_mkwrite" so you'll need to pull that one
in as well.

Changes since v2:
  * completely rewritten
  * freezing is now blocked at VFS entry points
  * two stage freezing to handle both mmapped writes and other IO

The biggest changes since v1:
  * have two counters to provide safe state transitions for SB_FREEZE_WRITE
    and SB_FREEZE_TRANS states
  * use percpu counters instead of own percpu structure
  * added documentation fixes from the old fs freezing series
  * converted XFS to use SB_FREEZE_TRANS counter instead of its private
    m_active_trans counter

								Honza

CC: Alex Elder <elder@...nel.org>
CC: Anton Altaparmakov <anton@...era.com>
CC: Ben Myers <bpm@....com>
CC: Chris Mason <chris.mason@...cle.com>
CC: cluster-devel@...hat.com
CC: "David S. Miller" <davem@...emloft.net>
CC: fuse-devel@...ts.sourceforge.net
CC: "J. Bruce Fields" <bfields@...ldses.org>
CC: Joel Becker <jlbec@...lplan.org>
CC: KONISHI Ryusuke <konishi.ryusuke@....ntt.co.jp>
CC: linux-btrfs@...r.kernel.org
CC: linux-ext4@...r.kernel.org
CC: linux-nfs@...r.kernel.org
CC: linux-nilfs@...r.kernel.org
CC: linux-ntfs-dev@...ts.sourceforge.net
CC: Mark Fasheh <mfasheh@...e.com>
CC: Miklos Szeredi <miklos@...redi.hu>
CC: ocfs2-devel@....oracle.com
CC: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
CC: Steven Whitehouse <swhiteho@...hat.com>
CC: "Theodore Ts'o" <tytso@....edu>
CC: xfs@....sgi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/