How to call ioctl from kernel space in Linux kernel after version 5.18 and in 64-bit arch.

[gigli_korg]

Good morning,

I try to rebuild a Linux device driver from previous release (4.19) in recent kernels, namely 6.1.22 on embedded platforms, ARM64 arch.

THe driver manage a tty device.

The problems start to occur when I invoke `unlocked_ioctl()` function similar to the user-space usage.

THe following code try to summarize the usage to maintain:

char device_name = "/dev/my-tty";
int open_mode = O_RDWR | O_NOCTTY;
struct file * file = filp_open(device_name, open_mode, 0);
/* ... */
struct ktermios *ntermios;
int ldisc;

/* ... something on ldisc and ntermios ... */

fs = get_fs();
set_fs(get_ds());
int retval = file->f_op->unlocked_ioctl(file, TCSETS, (unsigned long)&ntermios));
set_fs(fs);

/* ... */

fs = get_fs();
set_fs(get_ds());
int retval = file->f_op->unlocked_ioctl(file, TIOCSETD, (unsigned long)&ldisc));
set_fs(fs);

/* ... */

in both cases the return value of the two calls to `unlocked_ioctl` is -14 (`EFAULT` / Bad Address).
The is in the presence of function `copy_from_user()`, ... that simply fails.

Search in code and on several forum, I found several details about the "set_fs()"-dance removal, but nothing about solution or alternative approaches.

As example of the most meaning full resource I visited are the followings:
- https://lwn.net/Articles/832121/
- https://stackoverflow.com/questions/74966928/deprecation-of-force-uaccess-begin-in-linux-kernel-5-19...
- https://stackoverflow.com/questions/11121319/how-to-use-ioctl-from-kernel-space-in-linux

The functions `force_uaccess_begin()` and `force_uaccess_end()`, `get_ds()`, `set_ds()`, `get_fs()`, as well as type `mm_segment_t` are not present any more (at least for ARM64 arch).

Basically the questions are the followings:

- How can I drive a device, as a tty, from kernel space?
- Is it possible yet?
- Are there alternatives to the `set_fs()`-dance? Is the approach, if any, completely different?
- Do you examples, maybe on linux kernel source code, about module/driver that have this kind of problem solved?

Any comment is appreciated.

Stefano

[Bio_TICFSL]

Hello,

I think is not possible to managed your task, also you have to base on a nxp BSP and 5.18 there is no BSP for that version.

Regards

[gigli_korg]

Hello Bio_TICFSL

you wrote "I think is not possible to managed your task,",

but why?

I suppose NXP too writes driver probably maintaining them during crossing ARM archs (as well 32 bit as wall 64 bit) and, during mainline kernel releses (and changes).
I suppose NXP developers adapt their driver. So, about

Thanks in advance.

gigli_korg.

[gigli_korg]

Hello,
the BSP is 6.1.22,, from NXP github site (https://github.com/nxp-real-time-edge-sw/real-time-edge-linux) and I work on iMX8MP cistom board.

I wrote version 5.18 (referring to the mainline of linux kernel version) that is the version affected by code changing.

Thanks in advance.

Stefano