Re: Should linuxkpi linux_file_ioctl support flexible array copy?

Hi Zhenlei,

Sorry for the late reply due to the Spring Festival. Happy Chinese New
Year to you!


>
> FreeBSD has Linuxulator ( Linux Binary Compatibility ) to run unmodified
> Linux applications. So if your goal is that, then I think the Linuxkpi
should
> be extended to support ioctl request with flexible arrays. I think that is
> one typical case to maintain *stable ABI* across different OSes ;)

You are right. However, since my primary goal for the GSoC project is to
reimplement the udmabuf driver logic to FreeBSD, strict binary
compatibility for unmodified Linux binaries is a "nice-to-have" rather
than a strict requirement for me right now. I am okay with recompiling
the userspace tool like qemu with a modified ABI to get the driver
working first.


>
> I did a quick look at the design of ioctl handling of FreeBSD and the
> LinuxKPI. I think it is doable to improve them to handle flexible
> arrays.

Regarding the two technical approaches you mentioned, I have some
thoughts:

The fundamental issue is that when _IOW is defined, sys_ioctl consumes
the userspace pointer and only passes the kernel copy. To support
flexible arrays, we must find a way (likely a hack) to propagate the
original userspace pointer down to the LinuxKPI layer while minimizing
the impact on the existing KBI. And then we can add a new field in
linux task_struct to store it for later use.


>
> A straight forward way is, pass both the userspace pointer along
> with the kernel's one to the driver, since the driver knows better
> whether the ioctl want to process flexible array or not.

For this approach, I think passing the userspace pointer explicitly to
the driver would change the ioctl function signature, which, as you
noted, risks breaking the KBI for all existing drivers.


>
> Another approach could be wrapping the handling of copyin / copyout
> of ioctl request entirely by the kernel, as the kernel has some
> improvements ( use local variable rather than malloc for small ioctl
> requests ), so drivers can also benefit it when possible.

For this approach, I assume you mean leveraging the existing wrappers
(like copy_from_user -> linux_copyin -> copyin). The challenge here is
that the wrapper needs a basis to decide whether to copy from the
pre-allocated kernel buffer (for the fixed header) or reach out to
userspace (for the flexible array).

They all relies on the access to the original userspace pointer, which
brings us back to the initial problem of retrieving that pointer through
sys_ioctl.


> Either way may want some efforts and I see KBI changes. So it is
> important to know how many drivers want this feature.

I plan to do a comprehensive survey of other drivers that might rely on
flexible arrays to see if this is a common pain point. I will try to
report back with my findings after the holiday.


>
> Good luck with you !

Thanks for your patience and guidance!
As a kernel rookie, I would greatly appreciate it if you could point out
any of my misunderstandings.

>
> Best regards,
> Zhenlei

Best Regards,
Zishun Yi