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: <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
Powered by blists - more mailing lists