All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaoxie@huawei.com>
To: <dsterba@suse.cz>, Qu Wenruo <quwenruo@cn.fujitsu.com>,
	Chris Mason <clm@fb.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock.
Date: Mon, 26 Jan 2015 08:31:26 +0800	[thread overview]
Message-ID: <54C58ADE.9090608@huawei.com> (raw)
In-Reply-To: <20150123165949.GR13289@twin.jikos.cz>

On Fri, 23 Jan 2015 17:59:49 +0100, David Sterba wrote:
> On Wed, Jan 21, 2015 at 03:04:02PM +0800, Miao Xie wrote:
>>> Pending changes are *not* only mount options. Feature change and label change
>>> are also pending changes if using sysfs.
>>
>> My miss, I don't notice feature and label change by sysfs.
>>
>> But the implementation of feature and label change by sysfs is wrong, we can
>> not change them without write permission.
> 
> Label change does not happen if the fs is readonly. If the filesystem is
> RW and label is changed through sysfs, then remount to RO will sync the
> filesystem and the new label will be saved.
> 
> The sysfs features write handler is missing that protection though, I'll
> send a patch.

First, the R/O protection is so cheap, there is a race between R/O remount and
label/feature change, please consider the following case:
	Remount R/O task		Label/Attr Change Task
					Check R/O
	remount ro R/O
					change Label/feature

Second, it forgets to handle the freezing event.

> 
>>> For freeze, it's not the same problem since the fs will be unfreeze sooner or
>>> later and transaction will be initiated.
>>
>> You can not assume the operations of the users, they might freeze the fs and
>> then shutdown the machine.
> 
> The semantics of freezing should make the on-device image consistent,
> but still keep some changes in memory.
> 
>>>>> For example, if we change the features/label through sysfs, and then umount
>>>>> the fs,
>>>> It is different from pending change.
>>> No, now features/label changing using sysfs both use pending changes to do the
>>> commit.
>>> See BTRFS_PENDING_COMMIT bit.
>>> So freeze -> change features/label -> sync will still cause the deadlock in the
>>> same way,
>>> and you can try it yourself.
>>
>> As I said above, the implementation of sysfs feature and label change is wrong,
>> it is better to separate them from the pending mount option change, make the
>> sysfs feature and label change be done in the context of transaction after
>> getting the write permission. If so, we needn't do anything special when sync
>> the fs.
> 
> That would mean to drop the write support of sysfs files that change
> global filesystem state (label and features right now). This would leave
> only the ioctl way to do that. I'd like to keep the sysfs write support
> though for ease of use from scripts and languages not ioctl-friendly.
> .

not drop the write support of sysfs, just fix the bug and make it change the
label and features under the writable context.

Thanks
Miao

      reply	other threads:[~2015-01-26  0:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  7:42 [PATCH] btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock Qu Wenruo
2015-01-19 14:06 ` David Sterba
2015-01-20  2:51   ` Qu Wenruo
2015-01-20  2:53     ` Qu Wenruo
2015-01-20  3:06       ` Miao Xie
2015-01-20  3:17         ` Qu Wenruo
2015-01-20  8:16           ` Miao Xie
2015-01-20  0:19 ` Miao Xie
2015-01-20  0:26   ` Qu Wenruo
2015-01-20 17:13 ` David Sterba
2015-01-21  0:58   ` Qu Wenruo
2015-01-21  1:05     ` Chris Mason
2015-01-21  1:09       ` Qu Wenruo
2015-01-21  1:10         ` Chris Mason
2015-01-21  3:10           ` Miao Xie
2015-01-21  3:15             ` Qu Wenruo
2015-01-21  3:26               ` Miao Xie
2015-01-21  3:53                 ` Qu Wenruo
2015-01-21  7:04                   ` Miao Xie
2015-01-21  7:47                     ` Qu Wenruo
2015-01-21  8:46                       ` Miao Xie
2015-01-23 17:39                       ` David Sterba
2015-01-23 18:21                         ` Chris Mason
2015-01-23 16:59                     ` David Sterba
2015-01-26  0:31                       ` Miao Xie [this message]

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=54C58ADE.9090608@huawei.com \
    --to=miaoxie@huawei.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.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.