From: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
To: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Josef Bacik <jbacik@fusionio.com>,
Eric Sandeen <sandeen@redhat.com>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Luiz Capitulino <lcapitulino@redhat.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 12/17] fsfreeze: sb-level/bdev-level fsfreeze integration
Date: Thu, 10 Jan 2013 18:57:17 +0900 [thread overview]
Message-ID: <50EE907D.2050804@lab.ntt.co.jp> (raw)
In-Reply-To: <20130109163737.GE17353@quack.suse.cz>
On 2013/01/10 01:37, Jan Kara wrote:
> On Mon 07-01-13 20:38:24, Fernando Luis Vázquez Cao wrote:
>> As things stand now a filesystem frozen through the in-kernel bdev
level API
>> can be thawed using the userspace sb level API, which can lead to
accidental
>> corruption of filesystem snapshots and backups.
>>
>> To address this problem we modify the in-kernel API so that we can tell
>> fsfreeze that a kernel initiated freeze is in progress and that the
filesystem
>> should not be thawed no matter how many times the FITHAW ioctl is
invoked.
>
> I'm not sure if this isn't going too far in the direction of trying to
> prevent sysadmin to shoot himself in the foot. For well written
applications
> where FITHAW and FIFREEZE are paired, things should work OK after your
> initial fixes. And if someone calls unpaired FITHAW, things can break
> spectacularly anyway for other users of FIFREEZE. So I just wouldn't
bother
> with any more protections. What do you think?
I think that FITHAW/FIFREEZE should not interfere with
(freeze/thaw)_bdev, which is an internal kernel API. It could be the
case that users of freeze_bdev (external modules) cannot handle a
scenario where a frozen filesystem is unexpectedly thawed through the
userspace API.
This kind of protection is also beneficial in virtualization
environments where there can be hypervisor initiated uses of the
fsfreeze API (this is a reality in KVM with the advent of QEMU's guest
agent), which means that we effectively have two administrative
domains (the guest's and hypervisor's). It would be nice if we can
avoid situations where a guest initiated dm-snapshot is not affected
by a spurious FITHAW request from the hypervisor.
If the added complexity is acceptable I think this king of protections
is desirable.
- Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-01-10 9:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 11:18 [PATCH v6 0/17] fsfreeze: miscellaneous fixes and cleanups Fernando Luis Vázquez Cao
2013-01-07 11:21 ` [PATCH 1/17] vfs: add __iterate_supers() and helpers around it Fernando Luis Vázquez Cao
2013-01-07 11:22 ` [PATCH 2/17] fsfreeze: add unlocked version of thaw_super Fernando Luis Vázquez Cao
2013-01-07 11:23 ` [PATCH 3/17] fsfreeze: fix emergency thaw infinite loop Fernando Luis Vázquez Cao
2013-01-07 11:26 ` [PATCH 4/17] fsfreeze: emergency thaw will deadlock on s_umount Fernando Luis Vázquez Cao
2013-01-09 16:12 ` Jan Kara
2013-01-07 11:27 ` [PATCH 5/17] xfs: switch to using super methods for fsfreeze Fernando Luis Vázquez Cao
2013-01-07 11:29 ` [PATCH 6/17] fsfreeze: move emergency thaw code to fs/super.c Fernando Luis Vázquez Cao
2013-01-07 11:30 ` [PATCH 7/17] fsfreeze: fix nested freezing of sb-less bdevs Fernando Luis Vázquez Cao
2013-01-09 16:24 ` Jan Kara
2013-01-07 11:32 ` [PATCH 8/17] fsfreeze: allow bdev level thaws when the sb is unfrozen Fernando Luis Vázquez Cao
2013-01-09 16:26 ` Jan Kara
2013-01-07 11:34 ` [PATCH 9/17] fsfreeze: freeze_super and thaw_bdev don't play well together Fernando Luis Vázquez Cao
2013-01-07 11:35 ` [PATCH 10/17] fsfreeze: automatically thaw on umount Fernando Luis Vázquez Cao
2013-01-09 17:20 ` Jan Kara
2013-01-10 9:14 ` Fernando Luis Vazquez Cao
2013-01-07 11:36 ` [PATCH 11/17] fsfreeze: add thaw_super_force Fernando Luis Vázquez Cao
2013-01-07 11:38 ` [PATCH 12/17] fsfreeze: sb-level/bdev-level fsfreeze integration Fernando Luis Vázquez Cao
2013-01-09 16:37 ` Jan Kara
2013-01-10 9:57 ` Fernando Luis Vazquez Cao [this message]
2013-01-07 11:39 ` [PATCH 13/17] fsfreeze: unfreeze bdevs in addition to filesystems during emergency thaw Fernando Luis Vázquez Cao
2013-01-09 16:41 ` Jan Kara
2013-01-07 11:41 ` [PATCH 14/17] vfs: leverage bd_super in get_super and get_active_super Fernando Luis Vázquez Cao
2013-01-09 16:44 ` Jan Kara
2013-01-07 11:42 ` [PATCH 15/17] btrfs: store pointer to superblock in bd_super Fernando Luis Vázquez Cao
2013-01-07 11:43 ` [PATCH 16/17] fsfreeze: allow freeze counter lock nesting Fernando Luis Vázquez Cao
2013-01-07 11:44 ` [PATCH 17/17] fsfreeze: export freeze_count through mountinfo Fernando Luis Vázquez Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50EE907D.2050804@lab.ntt.co.jp \
--to=fernando_b1@lab.ntt.co.jp \
--cc=dchinner@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jbacik@fusionio.com \
--cc=lcapitulino@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).