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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <141752A3-EDF1-4ABC-919D-4170B0455948@whamcloud.com>
Date:	Mon, 16 Apr 2012 22:10:50 -0700
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jan Kara <jack@...e.cz>, 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 5:43 PM, Dave Chinner wrote:
> On Mon, Apr 16, 2012 at 03:02:50PM -0700, Andreas Dilger wrote:
>> 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...
> 
> Unlinked-but-open files are the reason that XFS dirties the log
> after the freeze process is complete. This ensures that if the
> system crashes while the filesystem is frozen then log recovery
> during the next mount will process the unlinked (orphaned) inodes
> and free the correctly. i.e. you can still freeze a filesystem with
> inodes in this state successfully and have everythign behave as
> you'd expect.
> 
> I'm not sure how other filesystems handle this problem, but perhaps
> pushing this check down into filesystem specific code or adding a
> superblock feature flag might be a way to allow filesystems to
> handle this case in the way they think is best...

The ext3/4 code has long been able to handle open-unlinked files
properly after a crash (they are put into a singly-linked list from
the superblock on disk that is processed after journal recovery).

The issue here is that blocking freeze from succeeding with open-
unlinked files is an unreasonable assumption of this patch, and
I don't think it is acceptable to land this patchset (which IMHO
would prevent nearly every Gnome system from freezing unless these
apps have changed their behaviour in more recent releases).

Like you suggest, filesystems that handle this correctly should be
able to flag or otherwise indicate that this is OK, and allow the
freeze to continue.  For other filesystems that do not handle
open-unlinked file consistency during a filesystem freeze/snapshot
whether this should even be considered a new case, or is something
that has existed for ages already.

The other question is whether this is still a problem even for
filesystems handling the consistency issue, but from Jan's comment
above there is a new locking issue related to mmap_sem being added?

Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/




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