linux-kernel - Re: [RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage

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: <20100610124553.GB29772@dhcp231-156.rdu.redhat.com>
Date:	Thu, 10 Jun 2010 08:45:53 -0400
From:	Josef Bacik <josef@...hat.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	viro@...IV.linux.org.uk, josef@...hat.com, jeffmerkey@...il.com
Subject: Re: [RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage

On Thu, Jun 10, 2010 at 05:19:49PM +1000, Dave Chinner wrote:
> The following series is for to address bugs in the emergency thawing code, as
> well as mismatcheѕ with freezing at the block layer and the superblock that
> break the freeze/thaw nesting order.
> 
> The first two patches fix the emergency thaw infinite loop reported by Jeff
> Merkey and the deadlock on sb->s_umount that the infinite loop hid. These may
> be stable kernel candidates.
> 
> The remainder of the patches address the bdev/sb mismatch and the fact that sb
> level freezing does not nest correctly. For all the places that the bdev
> interfaces are used, we need a superblock anyway so we may as well make
> freeze/thaw work only at the sb level. As such, this series moves all the
> nesting code to the sb from the bdev level and removes the
> freeze_bdev/thaw_bdev interfaces completely. It also converts the emergency
> thaw to work at the superblock level such that it will now thaw manually frozen
> filesystems.
> 
> A *big* outstanding problem still exists - freezing takes an active reference
> to the superblock, so unmounting an frozen filesystem has some nasty and
> unexpected side effects. The existing code results in an unmountable block
> device:
> 
> # mount /dev/vda /mnt/test
> # xfs_freeze -f /mnt/test
> # umount /mnt/test
> # grep test /proc/mounts
> # mkfs.xfs -f -l size=128m /dev/vda
> mkfs.xfs: /dev/vda contains a mounted filesystem
> Usage: mkfs.xfs
> ....
> # mount /dev/vda /mnt/test
> mount: /dev/vda already mounted or /mnt/test busy
> #
> 
> At this point I can't get access to /dev/vda and needs a reboot to
> get it and /mnt/test back.
> 
> This patch series results in the block device being mountable, but
> remains frozen across unmount/mount:
> 
> # mount /dev/vda /mnt/test
> # xfs_freeze -f /mnt/test
> # umount /mnt/test
> # grep test /proc/mounts
> # mkfs.xfs -f -l size=128m /dev/vda
> mkfs.xfs: /dev/vda contains a mounted filesystem
> Usage: mkfs.xfs
> ....
> # mount /dev/vda /mnt/test
> # touch /mnt/test/foo &
> [1] 2647
> #
> # xfs_freeze -u /mnt/test
> [1]+  Done                    sudo touch /mnt/test/foo
> # umount /mnt/test
> # mkfs.xfs -f -l size=128m /dev/vda
> meta-data=/dev/vda               isize=256    agcount=4, agsize=262144 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=1048576, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=32768, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> #
> 
> This behaviour is only marginally better than the existing behaviour
> (at least you can release the references). However, I don't really
> like either option - we used to disallow umount on a frozen
> filesystems to avoid this problem.
> 
> So What is really supposed to happen when we unmount a frozen
> superblock? Should unmount return EBUSY?  Should it be automatically
> thawed so it doesn't affect block device behaviour after unmount?
> Something else?
>

My vote is for EBUSY, that way we don't get this weird unexpected behavior
thing.  Plus if dm is doing a snapshot or whatever, unfreezing the fs to let it
unmount in the middle of it doing its thing could be unfun.  Thanks,

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