linux-ext4 - Re: [PATCH 00/19 v5] 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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <C9A0E2F0-ED57-40D6-9F75-5D72D45D21F0@dilger.ca>
Date:	Mon, 16 Apr 2012 15:02:50 -0700
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Al Viro <viro@...IV.linux.org.uk>, dchinner@...hat.com,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, 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: Re: [PATCH 00/19 v5] Fix filesystem freezing deadlocks

On 2012-04-16, at 9:13 AM, Jan Kara wrote:
> 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).

Looking at a desktop system, I think it is very typical that there
are open-unlinked files present, so I don't know if this is really
an acceptable solution.  It isn't clear from your comments whether
this is a blanket refusal for all open-unlinked files, or only in
some particular cases...

lsof | grep deleted
nautilus  25393  adilger   19r      REG           253,0      340     253954 /home/adilger/.local/share/gvfs-metadata/home (deleted)
nautilus  25393  adilger   20r      REG           253,0    32768     253964 /home/adilger/.local/share/gvfs-metadata/home-f332a8f3.log (deleted)
gnome-ter 25623  adilger   22u      REG            0,18    17841    2717846 /tmp/vtePIRJCW (deleted)
gnome-ter 25623  adilger   23u      REG            0,18     5568    2717847 /tmp/vteDCSJCW (deleted)
gnome-ter 25623  adilger   29u      REG            0,18      480    2728484 /tmp/vte6C1TCW (deleted)

Cheers, Andreas





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