diff mbox

[1/2,V2] fs: hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

Message ID 4a4f33c3-2173-9795-f4e4-1e9d338fd9a7@sandeen.net (mailing list archive)
State New, archived
Headers show

Commit Message

Eric Sandeen May 10, 2018, 6:13 p.m. UTC 
Move the btrfs label ioctls up to the vfs for general use.

This retains 256 chars as the maximum size through the interface, which
is the btrfs limit and AFAIK exceeds any other filesystem's maximum
label size.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Reviewed-by: David Sterba <dsterba@suse.com>
---

V2: note that hoisted btrfs ioctls exist in ioctl-number.txt, new since
    reviews but I took a little license.



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Al Viro May 10, 2018, 7:16 p.m. UTC | #1 
On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> Move the btrfs label ioctls up to the vfs for general use.
> 
> This retains 256 chars as the maximum size through the interface, which
> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> label size.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> Reviewed-by: David Sterba <dsterba@suse.com>

No objections (and it obviously ought to go through btrfs tree).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba May 11, 2018, 2:10 p.m. UTC | #2 
On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> > Move the btrfs label ioctls up to the vfs for general use.
> > 
> > This retains 256 chars as the maximum size through the interface, which
> > is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> > label size.
> > 
> > Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> > Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> > Reviewed-by: David Sterba <dsterba@suse.com>
> 
> No objections (and it obviously ought to go through btrfs tree).

I can take it through my tree, but Eric mentioned that there's a patch
for xfs that depends on it. In this case it would make sense to take
both patches at once via the xfs tree. There are no pending conflicting
changes in btrfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chris Mason May 11, 2018, 2:32 p.m. UTC | #3 
On 11 May 2018, at 10:10, David Sterba wrote:

> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>>> Move the btrfs label ioctls up to the vfs for general use.
>>>
>>> This retains 256 chars as the maximum size through the interface, 
>>> which
>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
>>> label size.
>>>
>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
>>> Reviewed-by: David Sterba <dsterba@suse.com>
>>
>> No objections (and it obviously ought to go through btrfs tree).
>
> I can take it through my tree, but Eric mentioned that there's a patch
> for xfs that depends on it. In this case it would make sense to take
> both patches at once via the xfs tree. There are no pending 
> conflicting
> changes in btrfs.

Probably easiest to just have a separate pull dedicated just for this 
series.  That way it doesn't really matter which tree it goes through.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Sandeen May 11, 2018, 2:36 p.m. UTC | #4 
On 5/11/18 9:32 AM, Chris Mason wrote:
> On 11 May 2018, at 10:10, David Sterba wrote:
> 
>> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>>>> Move the btrfs label ioctls up to the vfs for general use.
>>>>
>>>> This retains 256 chars as the maximum size through the interface, which
>>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
>>>> label size.
>>>>
>>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
>>>> Reviewed-by: David Sterba <dsterba@suse.com>
>>>
>>> No objections (and it obviously ought to go through btrfs tree).
>>
>> I can take it through my tree, but Eric mentioned that there's a patch
>> for xfs that depends on it. In this case it would make sense to take
>> both patches at once via the xfs tree. There are no pending conflicting
>> changes in btrfs.
> 
> Probably easiest to just have a separate pull dedicated just for this series.  That way it doesn't really matter which tree it goes through.

Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
independent of any btrfs changes, right - there's nothing wrong w/ redefining
the common ioctl under a different name in btrfs.  So the fs.h patch could go first,
through the xfs tree since it'll be using it.

Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
the common ioctls, or act on them directly as my patch did, etc.  Would that be
a better plan?  IOWs there's no urgent need to coordinate a btrfs change.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba May 11, 2018, 2:41 p.m. UTC | #5 
On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> On 5/11/18 9:32 AM, Chris Mason wrote:
> > On 11 May 2018, at 10:10, David Sterba wrote:
> > 
> >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> >>>> Move the btrfs label ioctls up to the vfs for general use.
> >>>>
> >>>> This retains 256 chars as the maximum size through the interface, which
> >>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> >>>> label size.
> >>>>
> >>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> >>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> >>>> Reviewed-by: David Sterba <dsterba@suse.com>
> >>>
> >>> No objections (and it obviously ought to go through btrfs tree).
> >>
> >> I can take it through my tree, but Eric mentioned that there's a patch
> >> for xfs that depends on it. In this case it would make sense to take
> >> both patches at once via the xfs tree. There are no pending conflicting
> >> changes in btrfs.
> > 
> > Probably easiest to just have a separate pull dedicated just for this series.  That way it doesn't really matter which tree it goes through.
> 
> Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
> independent of any btrfs changes, right - there's nothing wrong w/ redefining
> the common ioctl under a different name in btrfs.  So the fs.h patch could go first,
> through the xfs tree since it'll be using it.
> 
> Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
> the common ioctls, or act on them directly as my patch did, etc.  Would that be
> a better plan?  IOWs there's no urgent need to coordinate a btrfs change.

Agreed, I like that plan.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Darrick J. Wong May 12, 2018, 12:20 a.m. UTC | #6 
On Fri, May 11, 2018 at 04:41:45PM +0200, David Sterba wrote:
> On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> > On 5/11/18 9:32 AM, Chris Mason wrote:
> > > On 11 May 2018, at 10:10, David Sterba wrote:
> > > 
> > >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> > >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> > >>>> Move the btrfs label ioctls up to the vfs for general use.
> > >>>>
> > >>>> This retains 256 chars as the maximum size through the interface, which
> > >>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> > >>>> label size.
> > >>>>
> > >>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> > >>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> > >>>> Reviewed-by: David Sterba <dsterba@suse.com>
> > >>>
> > >>> No objections (and it obviously ought to go through btrfs tree).
> > >>
> > >> I can take it through my tree, but Eric mentioned that there's a patch
> > >> for xfs that depends on it. In this case it would make sense to take
> > >> both patches at once via the xfs tree. There are no pending conflicting
> > >> changes in btrfs.
> > > 
> > > Probably easiest to just have a separate pull dedicated just for this series.  That way it doesn't really matter which tree it goes through.
> > 
> > Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
> > independent of any btrfs changes, right - there's nothing wrong w/ redefining
> > the common ioctl under a different name in btrfs.  So the fs.h patch could go first,
> > through the xfs tree since it'll be using it.
> > 
> > Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
> > the common ioctls, or act on them directly as my patch did, etc.  Would that be
> > a better plan?  IOWs there's no urgent need to coordinate a btrfs change.
> 
> Agreed, I like that plan.

Ok, I'll await a new series with all the patches that Eric wants to
squeeze through the xfs tree.  I don't mind carrying the btrfs changes
too, so long as they're one-liners and the btrfs maintainers ack/rvb it.

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 84bb74dcae12..1299df349b71 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -298,7 +298,8 @@  Code  Seq#(hex)	Include File		Comments
 0x90	00	drivers/cdrom/sbpcd.h
 0x92	00-0F	drivers/usb/mon/mon_bin.c
 0x93	60-7F	linux/auto_fs.h
-0x94	all	fs/btrfs/ioctl.h
+0x94	all	fs/btrfs/ioctl.h	Btrfs filesystem
+		and linux/fs.h		some lifted to vfs
 0x97	00-7F	fs/ceph/ioctl.h		Ceph file system
 0x99	00-0F				537-Addinboard driver
 					<mailto:buk@buks.ipn.de>
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 632e26d6f7ce..8feea790bd00 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -5444,6 +5444,10 @@  long btrfs_ioctl(struct file *file, unsigned int
 		return btrfs_ioctl_setflags(file, argp);
 	case FS_IOC_GETVERSION:
 		return btrfs_ioctl_getversion(file, argp);
+	case FS_IOC_GETFSLABEL:
+		return btrfs_ioctl_get_fslabel(file, argp);
+	case FS_IOC_SETFSLABEL:
+		return btrfs_ioctl_set_fslabel(file, argp);
 	case FITRIM:
 		return btrfs_ioctl_fitrim(file, argp);
 	case BTRFS_IOC_SNAP_CREATE:
@@ -5555,10 +5559,6 @@  long btrfs_ioctl(struct file *file, unsigned int
 		return btrfs_ioctl_quota_rescan_wait(file, argp);
 	case BTRFS_IOC_DEV_REPLACE:
 		return btrfs_ioctl_dev_replace(fs_info, argp);
-	case BTRFS_IOC_GET_FSLABEL:
-		return btrfs_ioctl_get_fslabel(file, argp);
-	case BTRFS_IOC_SET_FSLABEL:
-		return btrfs_ioctl_set_fslabel(file, argp);
 	case BTRFS_IOC_GET_SUPPORTED_FEATURES:
 		return btrfs_ioctl_get_supported_features(argp);
 	case BTRFS_IOC_GET_FEATURES:
diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
index c8d99b9ca550..af29cc9032a2 100644
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -823,10 +823,8 @@  enum btrfs_err_code {
 #define BTRFS_IOC_QUOTA_RESCAN_STATUS _IOR(BTRFS_IOCTL_MAGIC, 45, \
 			       struct btrfs_ioctl_quota_rescan_args)
 #define BTRFS_IOC_QUOTA_RESCAN_WAIT _IO(BTRFS_IOCTL_MAGIC, 46)
-#define BTRFS_IOC_GET_FSLABEL _IOR(BTRFS_IOCTL_MAGIC, 49, \
-				   char[BTRFS_LABEL_SIZE])
-#define BTRFS_IOC_SET_FSLABEL _IOW(BTRFS_IOCTL_MAGIC, 50, \
-				   char[BTRFS_LABEL_SIZE])
+#define BTRFS_IOC_GET_FSLABEL 	FS_IOC_GETFSLABEL
+#define BTRFS_IOC_SET_FSLABEL	FS_IOC_SETFSLABEL
 #define BTRFS_IOC_GET_DEV_STATS _IOWR(BTRFS_IOCTL_MAGIC, 52, \
 				      struct btrfs_ioctl_get_dev_stats)
 #define BTRFS_IOC_DEV_REPLACE _IOWR(BTRFS_IOCTL_MAGIC, 53, \
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index d2a8313fabd7..9d132f8f2df8 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -242,6 +242,8 @@  struct fsxattr {
 #define FICLONERANGE	_IOW(0x94, 13, struct file_clone_range)
 #define FIDEDUPERANGE	_IOWR(0x94, 54, struct file_dedupe_range)
 
+#define FSLABEL_MAX 256	/* Max chars for the interface; each fs may differ */
+
 #define	FS_IOC_GETFLAGS			_IOR('f', 1, long)
 #define	FS_IOC_SETFLAGS			_IOW('f', 2, long)
 #define	FS_IOC_GETVERSION		_IOR('v', 1, long)
@@ -251,8 +253,10 @@  struct fsxattr {
 #define FS_IOC32_SETFLAGS		_IOW('f', 2, int)
 #define FS_IOC32_GETVERSION		_IOR('v', 1, int)
 #define FS_IOC32_SETVERSION		_IOW('v', 2, int)
-#define FS_IOC_FSGETXATTR		_IOR ('X', 31, struct fsxattr)
-#define FS_IOC_FSSETXATTR		_IOW ('X', 32, struct fsxattr)
+#define FS_IOC_FSGETXATTR		_IOR('X', 31, struct fsxattr)
+#define FS_IOC_FSSETXATTR		_IOW('X', 32, struct fsxattr)
+#define FS_IOC_GETFSLABEL		_IOR(0x94, 49, char[FSLABEL_MAX])
+#define FS_IOC_SETFSLABEL		_IOW(0x94, 50, char[FSLABEL_MAX])
 
 /*
  * File system encryption support