Messages in this thread | | | Subject | Re: [f2fs-dev] [PATCH v3] f2fs: move ioctl interface definitions to separated file | From | Chao Yu <> | Date | Tue, 3 Nov 2020 16:17:40 +0800 |
| |
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 <ben@decadent.org.uk> 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 > . >
| |