From: Eric Sandeen <sandeen@redhat.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: "Fernando Luis Vázquez Cao" <fernando_b1@lab.ntt.co.jp>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Dave Chinner" <dchinner@redhat.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Jan Kara" <jack@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC 6/9] fsfreeze: move emergency thaw code to fs/super.c
Date: Thu, 13 Sep 2012 16:10:35 -0500 [thread overview]
Message-ID: <50524BCB.8090500@redhat.com> (raw)
In-Reply-To: <20120913190001.GH12994@localhost.localdomain>
On 9/13/12 2:00 PM, Josef Bacik wrote:
> On Thu, Sep 13, 2012 at 05:08:19AM -0600, Fernando Luis Vázquez Cao wrote:
>> It makes no sense having the emergency thaw code in fs/buffer.c when all of
>> it's operations are one superblocks and the code it executes is all in
>> fs/super.c. Move the code there and clean it up.
>>
>> Cc: Josef Bacik <jbacik@fusionio.com>
>> Cc: Eric Sandeen <sandeen@redhat.com>
>> Cc: Christoph Hellwig <hch@infradead.org>
>> Reviewed-by: Jan Kara <jack@suse.cz>
>> Signed-off-by: Dave Chinner <dchinner@redhat.com>
>> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
>> ---
>>
>> diff -urNp linux-3.6-rc5-orig/fs/buffer.c linux-3.6-rc5/fs/buffer.c
>> --- linux-3.6-rc5-orig/fs/buffer.c 2012-09-12 20:44:13.226112590 +0900
>> +++ linux-3.6-rc5/fs/buffer.c 2012-09-12 20:50:25.406058417 +0900
>> @@ -511,52 +511,6 @@ repeat:
>> return err;
>> }
>>
>> -static int thaw_super_emergency(struct super_block *sb)
>> -{
>> - int res;
>> - /* We were called from __iterate_supers with superblock lock taken
>> - * so we do not need to do it here. */
>> - res = __thaw_super(sb);
>> - if (!res)
>> - deactivate_locked_super(sb);
>> - else
>> - up_write(&sb->s_umount);
>> - return res;
>> -}
>> -
>> -static void do_thaw_one(struct super_block *sb, void *unused)
>> -{
>> - if (sb->s_bdev) {
>> - char b[BDEVNAME_SIZE];
>> - printk(KERN_WARNING "Emergency Thaw on %s.\n",
>> - bdevname(sb->s_bdev, b));
>> - }
>> - while (!thaw_super_emergency(sb));
>> -}
>> -
>> -static void do_thaw_all(struct work_struct *work)
>> -{
>> - __iterate_supers(do_thaw_one, NULL, true);
>> - kfree(work);
>> - printk(KERN_WARNING "Emergency Thaw complete\n");
>> -}
>> -
>> -/**
>> - * emergency_thaw_all -- forcibly thaw every frozen filesystem
>> - *
>> - * Used for emergency unfreeze of all filesystems via SysRq
>> - */
>> -void emergency_thaw_all(void)
>> -{
>> - struct work_struct *work;
>> -
>> - work = kmalloc(sizeof(*work), GFP_ATOMIC);
>> - if (work) {
>> - INIT_WORK(work, do_thaw_all);
>> - schedule_work(work);
>> - }
>> -}
>> -
>> /**
>> * sync_mapping_buffers - write out & wait upon a mapping's "associated" buffers
>> * @mapping: the mapping which wants those buffers written
>> diff -urNp linux-3.6-rc5-orig/fs/super.c linux-3.6-rc5/fs/super.c
>> --- linux-3.6-rc5-orig/fs/super.c 2012-09-12 20:24:10.474041390 +0900
>> +++ linux-3.6-rc5/fs/super.c 2012-09-12 20:50:42.546044906 +0900
>> @@ -1475,3 +1475,49 @@ int thaw_super(struct super_block *sb)
>> return res;
>> }
>> EXPORT_SYMBOL(thaw_super);
>> +
>> +static int thaw_super_emergency(struct super_block *sb)
>> +{
>> + int res;
>> + /* We were called from __iterate_supers with superblock lock taken
>> + * so we do not need to do it here. */
>> + res = __thaw_super(sb);
>> + if (!res)
>> + deactivate_locked_super(sb);
>> + else
>> + up_write(&sb->s_umount);
>> + return res;
>> +}
>
> So unless I'm missing something this is wrong. We do __iterate_supers() which
> does down_write(sb) and then call into this. Lets imagine a perfect world where
> the sb was only frozen once. So we go into __thaw_super() and return 0 because
> we were successfull and do deactivate_locked_super() which does
> up_write(s_umount), and then we loop because we want to get an -EINVAL to know
> we completely unfroze, so we call into __thaw_super(sb) without s_umount held
> and then we get our error and do up_write(s_umount) _again_. So this needs to
> be reworked to be correct ;). Thanks,
The stupid emergency sysrq thing was my fault (at someone else's suggestion) ;)
It's caused a lot of woe, and hasn't worked for two years. Should we keep it?
-Eric
> Josef
>
--
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:[~2012-09-13 21:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 10:57 [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups Fernando Luis Vázquez Cao
2012-09-13 11:00 ` [PATCH 1/9] vfs: add __iterate_supers() helper Fernando Luis Vázquez Cao
2012-09-14 2:36 ` Eric Sandeen
2012-09-14 2:40 ` Fernando Luis Vazquez Cao
2012-09-13 11:01 ` [RFC 2/9] fsfreeze: add unlocked version of thaw_super Fernando Luis Vázquez Cao
2012-09-13 18:13 ` Eric Sandeen
2012-09-13 11:03 ` [RFC 3/9] fsfreeze: Prevent emergency thaw from looping infinitely Fernando Luis Vázquez Cao
2012-09-13 16:40 ` Eric Sandeen
2012-09-13 11:04 ` [RFC 4/9] fsfreeze: emergency thaw will deadlock on s_umount Fernando Luis Vázquez Cao
2012-09-13 11:07 ` [RFC 5/9] xfs: switch to using super methods for fsfreeze Fernando Luis Vázquez Cao
2012-09-13 11:08 ` [RFC 6/9] fsfreeze: move emergency thaw code to fs/super.c Fernando Luis Vázquez Cao
2012-09-13 19:00 ` Josef Bacik
2012-09-13 21:10 ` Eric Sandeen [this message]
2012-09-14 2:11 ` Fernando Luis Vazquez Cao
2012-09-14 1:59 ` Fernando Luis Vazquez Cao
2012-09-13 11:10 ` [PATCH 7/9] fsfreeze: freeze_super and thaw_bdev don't play well together Fernando Luis Vázquez Cao
2012-09-13 11:11 ` [PATCH 8/9] fsfreeze: add vfs ioctl to check freeze state Fernando Luis Vázquez Cao
2012-09-13 11:13 ` [PATCH 9/9] fsfreeze: add block device " Fernando Luis Vázquez Cao
2012-09-14 0:57 ` [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups Dave Chinner
2012-09-14 2:20 ` Fernando Luis Vazquez Cao
2012-09-14 2:33 ` Eric Sandeen
2012-09-14 2:48 ` Fernando Luis Vazquez Cao
2012-09-14 6:22 ` Fernando Luis Vazquez 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=50524BCB.8090500@redhat.com \
--to=sandeen@redhat.com \
--cc=dchinner@redhat.com \
--cc=fernando_b1@lab.ntt.co.jp \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jbacik@fusionio.com \
--cc=linux-fsdevel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.