From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org, clmason@fusionio.com
Subject: Re: [patch 1/7] [PATCH] btrfs: add ability to query/change feature bits online
Date: Mon, 16 Sep 2013 14:13:11 -0400 [thread overview]
Message-ID: <52374A37.60402@suse.com> (raw)
In-Reply-To: <20130916172651.GV6810@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]
On 9/16/13 1:26 PM, David Sterba wrote:
> On Tue, Sep 10, 2013 at 12:24:09AM -0400, Jeff Mahoney wrote:
>> +static int btrfs_ioctl_set_features(struct file *file, void __user *arg)
>> +{
>> + struct btrfs_root *root = BTRFS_I(file_inode(file))->root;
>> + struct btrfs_super_block *super_block = root->fs_info->super_copy;
>> + struct btrfs_ioctl_feature_flags flags[2];
>> + struct btrfs_trans_handle *trans;
>> + u64 newflags;
>> + int ret;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + if (copy_from_user(flags, arg, sizeof(flags)))
>> + return -EFAULT;
>> +
>> + /* Nothing to do */
>> + if (!flags[0].compat_flags && !flags[0].compat_ro_flags &&
>> + !flags[0].incompat_flags)
>> + return 0;
>> +
>> + ret = check_feature(root, flags[0].compat_flags,
>> + flags[1].compat_flags, COMPAT);
>> + if (ret)
>> + return ret;
>> +
>> + ret = check_feature(root, flags[0].compat_ro_flags,
>> + flags[1].compat_ro_flags, COMPAT_RO);
>> + if (ret)
>> + return ret;
>> +
>> + ret = check_feature(root, flags[0].incompat_flags,
>> + flags[1].incompat_flags, INCOMPAT);
>> + if (ret)
>> + return ret;
>> +
>> + trans = btrfs_start_transaction(root, 1);
>
> It's ok to use 0 here, it's a superblock change and not related the the
> metadata (similar to changing the label).
>
>> + if (IS_ERR(trans))
>> + return PTR_ERR(trans);
>> +
>> + spin_lock(&root->fs_info->super_lock);
>> + newflags = btrfs_super_compat_flags(super_block);
>> + newflags |= flags[0].compat_flags & flags[1].compat_flags;
>> + newflags &= ~(flags[0].compat_flags & ~flags[1].compat_flags);
>> + btrfs_set_super_compat_flags(super_block, newflags);
>> +
>> + newflags = btrfs_super_compat_ro_flags(super_block);
>> + newflags |= flags[0].compat_ro_flags & flags[1].compat_ro_flags;
>> + newflags &= ~(flags[0].compat_ro_flags & ~flags[1].compat_ro_flags);
>> + btrfs_set_super_compat_ro_flags(super_block, newflags);
>> +
>> + newflags = btrfs_super_incompat_flags(super_block);
>> + newflags |= flags[0].incompat_flags & flags[1].incompat_flags;
>> + newflags &= ~(flags[0].incompat_flags & ~flags[1].incompat_flags);
>> + btrfs_set_super_incompat_flags(super_block, newflags);
>> + spin_unlock(&root->fs_info->super_lock);
>> +
>> + return btrfs_end_transaction(trans, root);
>
> I think it's better to use btrfs_commit_transaction. The ioctl is about
> to do a permanent change, any crash between ioctl and full commit will
> revert to previous state of the features. This is not IMO desirable from
> administrators POV.
>
> (Sidenote, IOC_SET_FSLABEL needs the same update.)
Done, and I have a patch to fix the setlabel case as well.
>> +}
>> +
>> --- a/include/uapi/linux/btrfs.h 2013-09-09 17:49:10.808003254 -0400
>> +++ b/include/uapi/linux/btrfs.h 2013-09-09 17:49:12.483979430 -0400
>> @@ -184,6 +184,12 @@ struct btrfs_ioctl_fs_info_args {
>> __u64 reserved[124]; /* pad to 1k */
>> };
>>
>> +struct btrfs_ioctl_feature_flags {
>> + __u64 compat_flags;
>> + __u64 compat_ro_flags;
>> + __u64 incompat_flags;
>
> I wonder if it makes sense to add spare bytes here, but does not seem
> necessary.
We could double the size to allow for expansion, but I think it'd
probably make more sense to add another ioctl later if we end up getting
up to 64 features in a field.
>> +};
>> @@ -579,4 +585,10 @@ static inline char *btrfs_err_str(enum b
>> +#define BTRFS_IOC_GET_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags)
>> +#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags[2])
>> +#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags[3])
>
> The ioctl number 54 clashes with the OOB dedup merged into 3.12, 55 is
> for the in-bound dedup and Anand has claimed 56. I've allocated 57 for
> you and updated th wiki page:
>
> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Development_notes.2C_please_read
>
> Stefan's trick to reuse the same number is really neat.
Thanks, changed.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
next prev parent reply other threads:[~2013-09-16 18:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 4:24 [patch 0/7] btrfs: Add ability to query/modify feature bits while mounted Jeff Mahoney
2013-09-10 4:24 ` [patch 1/7] [PATCH] btrfs: add ability to query/change feature bits online Jeff Mahoney
2013-09-16 17:26 ` David Sterba
2013-09-16 18:13 ` Jeff Mahoney [this message]
2013-09-10 4:24 ` [patch 2/7] btrfs: export supported featured to sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 3/7] btrfs: Add per-super attributes " Jeff Mahoney
2013-10-26 19:00 ` Alex Lyakas
2013-10-26 19:24 ` Jeff Mahoney
2013-09-10 4:24 ` [patch 4/7] btrfs: publish per-super features " Jeff Mahoney
2013-09-10 4:24 ` [patch 5/7] btrfs: Add publishing of unknown features in sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 6/7] btrfs: Add ability to change features via sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 7/7] btrfs: use feature attribute names to print better error messages Jeff Mahoney
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=52374A37.60402@suse.com \
--to=jeffm@suse.com \
--cc=clmason@fusionio.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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).