Is it possible to call a user-space callback function from kernel space on Linux (ioctl)?

Question

Is it possible to extend the ioctl interface on Linux so that a user-space application can send a function pointer to a kernel-space driver?

I, in particular, think about how to control the flow in a user-controlled way, but do it in the kernel. These operations can be attached to the kernel module, but this would greatly facilitate development, since I did not have to mess with the kernel during development.

In particular, it will be a process:

• Data is read by the driver into the buffer.
• Data is processed by these user-defined functions.
• Some processing is in progress, possibly with some HW blocks.
• Data is used by the user space application.

Answer 1

I think that you can achieve what you want by indicating that your driver provides one or more character devices (or block devices) that open your user's applications.

Then you can use inotify ( linux magazine article ) to exchange kernel space data ->. Ioctl or write to device for user space -> transmit kernel events. Data exchange can also be achieved by reading / writing to one or more device files.

Alternatively, you can specify the filesystem entries / proc or / sys or use netlink.

You can also consider ksocket :

Ksocket is a linux 2.6 kernel module that provides bsd-style socket interfaces (namely socket, bind, listen, connect, receive, ...) for kernel developers for network transmission in the linux kernel space. The ksocket interfaces are the same as their equivalent in glibc, so even new developers for the kernel space will not have a barrier to the development of network interaction with the PROGRAM network.

Answer 2

I think you are asking for a square circle: if the kernel were to simply execute your userland function directly, it would not be userland, but rather a homebrew loading system. I assume that what you really want is a way to figure out what to do to make it all work without breaking your PC every time you make a mistake. You might be able to abuse signal handlers as a "callback" tool, but I'm too rusty to indicate how you will return to the kernel, as if a function call were being returned. The problem here is that in any context context of userland-> kernel, the kernel starts from a fresh stack, so the return address has long been gone. How about combining a signal handler with mmap'ing / dev / mem, and let your userland pseudo-driver directly populate the kernel driver data structures? But then you will return to reboot when you make a mistake, if you do not understand how to model only your driver data structures? Other repurposable mechanisms may include STREAMS and TTY; I think that they give some ability to transform. Of course, none of this is a good idea as a permanent solution!

Answer 3

Your use case continues to mention data.

Perhaps what you want to do is swap memory between the kernel and the user process. You could put data and / or commands into shared memory, and the process / kernel code on the other side could read it and do whatever. Calling get_user_pages_fast () can make the process memory available to the kernel, even if the process is not running.