Re: Should linuxkpi linux_file_ioctl support flexible array copy?

> On Feb 15, 2026, at 3:03 AM, yi zishun <[email protected]> wrote:
> 
> Hi Zhenlei,
> 
> Sorry for the late reply due to the Spring Festival. Happy Chinese New
> Year to you!

Happy Chinese New Year !

> 
> 
> > 
> > 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.

The KBI can change between major versions, or sometimes minor versions.
Existing design may or may not meet future requirements, that the reality.
But still developers are happy to see stable KBI :)
 
> 
> 
> > 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.

Glad to hear that !

> 
> 
> > 
> > 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

Best regards,
Zhenlei