From: Liu Bo <bo.li.liu@oracle.com>
To: Marco Stornelli <marco.stornelli@gmail.com>
Cc: liub.liubo@gmail.com, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH RFC] Btrfs: fix deadlock between sys_sync and freeze
Date: Wed, 15 Aug 2012 20:51:17 +0800 [thread overview]
Message-ID: <502B9B45.5070304@oracle.com> (raw)
In-Reply-To: <502A5CDA.2080806@gmail.com>
(CCed Jan, the author of freeze code)
On 08/14/2012 10:12 PM, Marco Stornelli wrote:
> Il 14/08/2012 15:53, Liu Bo ha scritto:
>> On 08/14/2012 08:59 PM, Marco Stornelli wrote:
>>> Il 14/08/2012 07:01, liub.liubo@gmail.com ha scritto:
>>>> From: Liu Bo <bo.li.liu@oracle.com>
>>>>
>>>> I found this while testing xfstests 068, the story is
>>>>
>>>> t1 t2
>>>> sys_sync thaw_super
>>>> iterate_supers
>>>> down_read(sb->s_umount) down_write(sb->s_umount) --->wait for t1
>>>> sync_fs (with wait mode)
>>>> start_transaction
>>>> sb_start_intwrite --------------------> wait for t2 to set s_writers.frozen to SB_UNFROZEN
>>>>
>>>> In this patch, I add an helper sb_start_intwrite_trylock() and use it before we
>>>> start_transaction in sync_fs() with wait mode so that we won't hit the deadlock.
>>>>
>>>
>>> IMHO, we should avoid to call the sync operation on a frozen fs. The freeze operation, indeed, already include a sync operation.
>>> According to man page, no other operation should modify the fs after the freeze.
>>> So for me the modification is inside sync_filesystem (and sync_one_sb).
>>
>> Do you mean that we should add the trylock check in sync_filesystem?
>>
>> But it seems to be useless because we already run into down_read(sb->s_umount) before starting sync_one_sb().
>>
>> thanks,
>> liubo
>>
>
> I meant that we should check if there are in a "complete" freeze state (according to the "states" of a freeze transaction) and simply skip the sync operation.
>
I'm ok with it.
What do you think about it, Jan? Any comments?
thanks,
liubo
> Marco
next prev parent reply other threads:[~2012-08-15 12:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 5:01 [PATCH RFC] Btrfs: fix deadlock between sys_sync and freeze liub.liubo
2012-08-14 12:59 ` Marco Stornelli
2012-08-14 13:53 ` Liu Bo
2012-08-14 14:12 ` Marco Stornelli
2012-08-15 12:51 ` Liu Bo [this message]
2012-08-15 13:12 ` Jan Kara
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=502B9B45.5070304@oracle.com \
--to=bo.li.liu@oracle.com \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=liub.liubo@gmail.com \
--cc=marco.stornelli@gmail.com \
/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.