Re: [f2fs-dev] [PATCH v3] f2fs: move ioctl interface definitions to separated file
On 11/03, Chao Yu wrote: > On 2020/11/3 11:22, Eric Biggers wrote: > > On Mon, Nov 02, 2020 at 02:21:31PM +0800, Chao Yu wrote: > > > +#define F2FS_IOC_MOVE_RANGE _IOWR(F2FS_IOCTL_MAGIC, 9, > > > \ > > > + struct f2fs_move_range) > > [...] > > > +#define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11, > > > \ > > > + struct f2fs_gc_range) > > [...] > > > + > > > +struct f2fs_gc_range { > > > + __u32 sync; > > > + __u64 start; > > > + __u64 len; > > > +}; > > [...] > > > +struct f2fs_move_range { > > > + __u32 dst_fd; /* destination fd */ > > > + __u64 pos_in; /* start position in src_fd */ > > > + __u64 pos_out; /* start position in dst_fd */ > > > + __u64 len; /* size to move */ > > > +}; > > > > These two structs are weird because there is implicit padding between the > > __u32 > > field and the following __u64 field on some 32-bit architectures (e.g. > > x86_32) > > but not others (e.g. arm32). > > > > But f2fs_compat_ioctl() doesn't handle these two ioctls specially, but > > rather > > just calls through to f2fs_ioctl(). That's wrong, and it means that > > F2FS_IOC_MOVE_RANGE and F2FS_IOC_GARBAGE_COLLECT_RANGE won't work when > > called > > from an x86_32 binary on an x86_64 kernel. > > Nice catch! > > > > > So something needs to be fixed. I wonder if it's safe to just explicitly > > add > > the padding field after the fact. If no one is actually using these two > > ioctls > > in a case where both userspace and the kernel lack the implicit padding > > (e.g., > > x86_32 userspace with x86_32 kernel), it should be fine... > > IIRC, Jaegeuk added those interfaces, I hope it's not the requirement from > other > f2fs userspace developers...if it is, there may be users. > > I found one patch in ext4 which fixes the similar issue, I guess we can fix > this > with the same way, thoughts? Agreed. Please fix along with f2fs-tools/f2fs_io. > > commit 4d92dc0f00a775dc2e1267b0e00befb783902fe7 > Author: Ben Hutchings > Date: Mon May 17 06:00:00 2010 -0400 > > ext4: Fix compat EXT4_IOC_ADD_GROUP > > struct ext4_new_group_input needs to be converted because u64 has > only 32-bit alignment on some 32-bit architectures, notably i386. > > Thanks, > > > > > - Eric > > . > >
Re: [f2fs-dev] [PATCH v3] f2fs: move ioctl interface definitions to separated file
On 2020/11/3 11:22, Eric Biggers wrote: On Mon, Nov 02, 2020 at 02:21:31PM +0800, Chao Yu wrote: +#define F2FS_IOC_MOVE_RANGE_IOWR(F2FS_IOCTL_MAGIC, 9, \ + struct f2fs_move_range) [...] +#define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11, \ + struct f2fs_gc_range) [...] + +struct f2fs_gc_range { + __u32 sync; + __u64 start; + __u64 len; +}; [...] +struct f2fs_move_range { + __u32 dst_fd; /* destination fd */ + __u64 pos_in; /* start position in src_fd */ + __u64 pos_out; /* start position in dst_fd */ + __u64 len; /* size to move */ +}; These two structs are weird because there is implicit padding between the __u32 field and the following __u64 field on some 32-bit architectures (e.g. x86_32) but not others (e.g. arm32). But f2fs_compat_ioctl() doesn't handle these two ioctls specially, but rather just calls through to f2fs_ioctl(). That's wrong, and it means that F2FS_IOC_MOVE_RANGE and F2FS_IOC_GARBAGE_COLLECT_RANGE won't work when called from an x86_32 binary on an x86_64 kernel. Nice catch! So something needs to be fixed. I wonder if it's safe to just explicitly add the padding field after the fact. If no one is actually using these two ioctls in a case where both userspace and the kernel lack the implicit padding (e.g., x86_32 userspace with x86_32 kernel), it should be fine... IIRC, Jaegeuk added those interfaces, I hope it's not the requirement from other f2fs userspace developers...if it is, there may be users. I found one patch in ext4 which fixes the similar issue, I guess we can fix this with the same way, thoughts? commit 4d92dc0f00a775dc2e1267b0e00befb783902fe7 Author: Ben Hutchings Date: Mon May 17 06:00:00 2010 -0400 ext4: Fix compat EXT4_IOC_ADD_GROUP struct ext4_new_group_input needs to be converted because u64 has only 32-bit alignment on some 32-bit architectures, notably i386. Thanks, - Eric .
Re: [f2fs-dev] [PATCH v3] f2fs: move ioctl interface definitions to separated file
On Mon, Nov 02, 2020 at 02:21:31PM +0800, Chao Yu wrote: > +#define F2FS_IOC_MOVE_RANGE _IOWR(F2FS_IOCTL_MAGIC, 9, \ > + struct f2fs_move_range) [...] > +#define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11, > \ > + struct f2fs_gc_range) [...] > + > +struct f2fs_gc_range { > + __u32 sync; > + __u64 start; > + __u64 len; > +}; [...] > +struct f2fs_move_range { > + __u32 dst_fd; /* destination fd */ > + __u64 pos_in; /* start position in src_fd */ > + __u64 pos_out; /* start position in dst_fd */ > + __u64 len; /* size to move */ > +}; These two structs are weird because there is implicit padding between the __u32 field and the following __u64 field on some 32-bit architectures (e.g. x86_32) but not others (e.g. arm32). But f2fs_compat_ioctl() doesn't handle these two ioctls specially, but rather just calls through to f2fs_ioctl(). That's wrong, and it means that F2FS_IOC_MOVE_RANGE and F2FS_IOC_GARBAGE_COLLECT_RANGE won't work when called from an x86_32 binary on an x86_64 kernel. So something needs to be fixed. I wonder if it's safe to just explicitly add the padding field after the fact. If no one is actually using these two ioctls in a case where both userspace and the kernel lack the implicit padding (e.g., x86_32 userspace with x86_32 kernel), it should be fine... - Eric