January 2021 - kernelnewbies@kernelnewbies.org

Restrict DMA Buffer to 32 bit Address
by Tal Lubko Jan. 14, 2021

Jan. 14, 2021

Hi I've PCI device which uses DMA engines and runs on 64 bit Linux with 512MB RAM.It has 32 bit register used to specify DMA buffer address so as far as I understand I need to restrict it DMA buffers addresses to 32 bit. I tried the following: err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));if (err) { exit...} dma_alloc_coherent(dev, 0x1000, &dma_handle, GFP_KERNEL) but when I print allocated buffer address I get the following 0x409993216 What am I missing here? Thanks,Tal

1 0

test
by bigbird2444＠163.com Jan. 14, 2021

Jan. 14, 2021

1 0

How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
by Jorge Fernandez Monteagudo Jan. 12, 2021

Jan. 12, 2021

Hi all, this is my first post in this mailing list... I hope to find an answer. I've post the question in stackoverflow with the same tittle with no answers yet. Since then, I've been able to reduce the demo kernel module to minimum in order to show but I see. The minimum kernel module code is attached at the end. My kernel module was working ok up to kernel 5.10.x. My kernel module adds a layer above the cdc-acm class driver to use all the infrastructure this driver because the hardware it controls has a ttyACMx device. The minimum kernel module code attached shows how I open the ttyACMx device and try to set the baudrate. Once the device is opened I use the unlocked_ioctl function with TCSETS to set the new device properties. ret = fd->f_op->unlocked_ioctl(fd, TCSETS, (unsigned long int) &newtio); I get an EFAULT (-14) error from this function. I've track down the error to drivers/tty/tty_ioctl.c, set_termios function in the next code: #ifdef TCGETS2 } else if (opt & TERMIOS_OLD) { if (user_termios_to_kernel_termios_1(&tmp_termios, (struct termios __user *)arg)) return -EFAULT; } else { where 'user_termios_to_kernel_termios_1' is a macro to 'copy_from_user' then I think there is a problem with the parameter 'newtio'. To solve this in the previous kernel versions ( < 5.10.x) I had the code with get_fs()/set_fs() but now these functions and the KERNEL_DS definitions are gone... As a reference when I run this kernel module in a 4.15.0-128-generic I get when inserted and removed: # dmesg ... [431743.226926] cdc_acm 3-5.2:1.0: ttyACM0: USB ACM device [431749.633030] testdrv:testdrv_init: testdrv_init [431749.633351] testdrv:testdrv_init: fd : 00000000e9327576 [431749.633355] testdrv:testdrv_init: fd->f_op: 00000000c761e065 [431749.633357] testdrv:testdrv_init: ioctl : 00000000608ed60c [431749.633517] testdrv:usbox_serial_baudrate_set: _unlocked_ioctl: 0 [431749.633519] testdrv:usbox_serial_baudrate_set: ret: 0 [431761.532905] testdrv:testdrv_exit: testdrv_exit and the same driver with 5.10.0-1-amd64: # dmesg ... [ 4.731179] cdc_acm 2-3:1.0: ttyACM0: USB ACM device ... [ 168.263871] testdrv: loading out-of-tree module taints kernel. [ 168.264337] testdrv:testdrv_init: testdrv_init [ 168.266360] testdrv:testdrv_init: fd : 00000000bd0e50a3 [ 168.266363] testdrv:testdrv_init: fd->f_op: 00000000dc488f77 [ 168.266364] testdrv:testdrv_init: ioctl : 00000000c31431c2 [ 168.266370] testdrv:usbox_serial_baudrate_set: _unlocked_ioctl: -14 [ 168.266371] testdrv:usbox_serial_baudrate_set: ret: -14 [ 168.266372] testdrv:testdrv_init: errno: EINVAL Anybody can help me to make it work the minimum kernel module attached? Thank you! Jorge ---- #define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__ #include <linux/kernel.h> #include <linux/module.h> #include <linux/file.h> #include <linux/tty.h> #include <linux/version.h> #include <linux/uaccess.h> /* ttyACM file descriptor */ static struct file *fd; static int usbox_serial_baudrate_set(struct file *fd) { int ret; mm_segment_t old_fs; struct termios newtio; //struct termios __user newtio; //void __user *unewtio = (void __user *) &newtio; memset(&newtio, 0, sizeof(newtio)); newtio.c_cflag = (B115200 | CS8 | CLOCAL | CREAD); #if LINUX_VERSION_CODE < KERNEL_VERSION(5,0,0) old_fs = get_fs(); set_fs( get_ds() ); #elif LINUX_VERSION_CODE < KERNEL_VERSION(5,10,0) old_fs = get_fs(); set_fs( KERNEL_DS ); #else old_fs = force_uaccess_begin(); #endif if (fd->f_op->unlocked_ioctl) { ret = fd->f_op->unlocked_ioctl(fd, TCSETS, (unsigned long int) &newtio); pr_info("_unlocked_ioctl: %d\n", ret); } else { ret = -ENOTTY; } #if LINUX_VERSION_CODE < KERNEL_VERSION(5,10,0) set_fs(old_fs); #else force_uaccess_end(old_fs); #endif pr_info("ret: %d\n", ret ); return ret; } static int __init testdrv_init(void) { pr_info("testdrv_init\n"); fd = filp_open( "/dev/ttyACM0", O_RDWR|O_NOCTTY, 0); if (IS_ERR(fd)) { pr_info("error from filp_open()\n"); return -ENODEV; } pr_info ("fd : %p\n", fd); pr_info ("fd->f_op: %p\n", fd->f_op); pr_info ("ioctl : %p\n", fd->f_op->unlocked_ioctl); if ((fd->f_op == NULL) || (fd->f_op->unlocked_ioctl == NULL)) { pr_info("errno: ENODEV\n"); return -ENODEV; } // Set baudrate. if (usbox_serial_baudrate_set(fd) != 0 ) { filp_close(fd, NULL); pr_info("errno: EINVAL\n"); return -EINVAL; } return 0; } static void __exit testdrv_exit(void) { pr_info("testdrv_exit\n"); if (fd != NULL) { filp_close(fd, NULL); fd = NULL; } } module_init(testdrv_init); module_exit(testdrv_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Unknonw"); MODULE_DESCRIPTION("testdrv");

2 9

Tutorial for "drivers/mmc/*"?
by Gabriel L. Somlo Jan. 9, 2021

Jan. 9, 2021

Hi, I'm debugging a driver for a (fpga-based soft core) microSD card Linux device, and the existing driver (in drivers/mmc/host/...) makes sense at first sight, but, either due to shortcomings in the softcore (Verilog by way of Migen) "hardware", or the actual Linux driver itself, suffers from intermittent data transfer errors. I find myself wishing I could get a top-down idea of how the Linux mmc layer is put together, so I could examine the driver in question with a critical eye, rather than my current approach, which is best described as "blind-man attempts to comprehend an elephant by touching various locations on its body, hoping the collected experiences will suddenly come into focus and begin to make sense". :D This latter approach gives me information that makes sense on first sight, when taken uncritically, but doesn't help me figure out the "unknown unknowns" :) The alternative, of course, would be to read the actual source code in "drivers/mmc/core/..." until I "know it by heart", and then look at my (and a few other existing) drivers in "drivers/mmc/host/..." to try and get an idea of what I'm missing. I'll go with the latter if necessary, but would prefer a gentler introduction to "drivers/mmc". Any (link, pointer to) a tutorial, assuming one exists, would be MUCH appreciated! Thanks, --Gabriel

2 1

Setting group/other write flags not honoured in open
by Nicky Chorley Jan. 8, 2021

Jan. 8, 2021

Hi folks, I hope it's OK to ask this question here. I'm reading The Linux Programming Interface and am beginning to get to grips with the file oriented system calls. I have a program that calls open to create a file, specifying the mode flags for owner, group, other read and write. The file is created sucessfully, but when I look at its permissions, I only see the read perms set for group and others: > ./create_file foo > ls -l foo -rw-r--r-- 1 nick users 0 Oct 31 14:52 foo Why would that be? The entirety of my program is #include <fcntl.h> #include <unistd.h> int main(int argc, char *argv[]) { int open_flags = O_CREAT | O_WRONLY | O_TRUNC; mode_t file_perms = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH; int output_fd = open(argv[1], open_flags, file_perms); close(output_fd); } I also ran the program with strace and the perms in the openat call are as I would expect: openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 I don't understand why the group and other write flags aren't being set. Could someone help shed some light on this please? I'm not sure what factors influence this, but I'm running openSUSE Leap 15.2, with kernel 5.3.18-lp152.47-default, gcc 7.5.0 and glibc 2.26. Thanks, Nicky

2 2

Linux has timerfd, signalfd and eventfd. Is it time for a "unionfd"?
by Joe Doe Jan. 6, 2021

Jan. 6, 2021

One of the architectures that Linux applications use, is to run in a loop that watches a number of FDs (e.g. epoll()) and react to the events from those FDs. Now let's say I am writing a communication library that users can use to send and receive messages to other processes over the network. And let's assume that for reasons, my library is using multiple connections internally. I have no way to construct my library in such a way that it will only export a single FD to the user, and hide the rest of the internal connections. I will either have to expose all the FDs, making it more difficult for the user, or I would have to run the library code in a different thread, and use eventfd to make the interface simpler. Having a "UnionFD" that would get triggered when one of my other FDs is ready for I/O would solve the problem. For example an API of the hypothetical library with the tools we have today might look something like this: int comm_lib_init(void); // Returns the "master" FD int comm_lib_accept(int master_fd); // Returns an FD when a new connection is accepted int comm_lib_send_message(int master_fd, const char *dest, void *data, size_t data_len); // If a new connection was required to send this message, then it will return the FD int comm_lib_recv_message(int master_fd, ...); The user of the library would have to do the bookkeeping for all the FDs that are returned by the above APIs themself. Instead with a "UnionFD", the API would only ever return a single FD and the user would call `comm_lib_send_message` and `comm_lib_recv_message` with this FD. E.g. the application's code would look something like that: comm_fd = comm_lib_init(); epollfd = poll_create1(0); ev.events = EPOLLIN; ev.data.fd = comm_fd; epoll_ctl(epollfd, EPOLL_CTL_ADD, comm_fd, &ev); for (;;) { fds = epoll_wait(epollfd, events, MAX_EVENTS, -1); } Once in the loop, the user doesn't have to worry about FD bookkeeping anymore. Another example would be a much simpler HTTP library. The library would just return a single "master_fd" that the user would plug in their epoll() and just call something like `get_next_request()` when the FD gets triggered. That way we could easily add this HTTP server to an epoll() loop that monitors other FDs as well. No more worrying about accept(), and per-connection FD bookkeeping. I believe a construct like this would help some popular existing libraries as well, like zeromq and the grpc library. Does the above make sense? Or is there already a way to achieve that in Linux that I am not aware of? Thanks, Joe

2 1

How should I understand the 'less-compatible' names in the compatible list in device tree?
by ckim＠etri.re.kr Jan. 6, 2021

Jan. 6, 2021

Hello, I need some help from linux people. This is part of a device file (linux/arch/arm/boot/dts/versatile-ab.dts) uart1: uart@101f2000 { compatible = "arm,pl011", "arm,primecell"; reg = <0x101f2000 0x1000>; interrupts = <13>; clocks = <&xtal24mhz>, <&pclk>; clock-names = "uartclk", "apb_pclk"; }; uart2: uart@101f3000 { compatible = "arm,pl011", "arm,primecell"; reg = <0x101f3000 0x1000>; interrupts = <14>; clocks = <&xtal24mhz>, <&pclk>; clock-names = "uartclk", "apb_pclk"; }; smc@10100000 { compatible = "arm,primecell"; reg = <0x10100000 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; }; mpmc@10110000 { compatible = "arm,primecell"; reg = <0x10110000 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; }; I've read about device tree but could not understand it clearly. I understood the kernel during its initialization searches through the device tree and compares the compatible field of the node with that of the driver. so for the uart1 node, it uses just the driver which has compatible field "arm,pl011". What effect does "arm,primecell" in the uart1 compatible field have? What are the nodes smc and mpmc above which has only "arm,primecell" in the compatible field? (are they memory controllers? They differ only by node names. Then, does name have meaning? not allowed to be given arbitrarily?) Are they common for all the node which have "arm,primecell" in the compatible list? (I found many nodes in arm socs or boards have "arm,primecell" in the compatible list. Does the kernel use the nodes data with less compatible(or generic) field(like "arm,primecell"), and overwrite or add information from the node with more compatible(or special) name? I would really appreciate it if someone explains it to me.. Thank you! Chan Kim

1 0

Re: Linux has timerfd, signalfd and eventfd. Is it time for a "unionfd"?
by Joe Doe Jan. 6, 2021

Jan. 6, 2021

I just realized that epoll can do exactly what I asked for, so please ignore!

1 0

How is RSDP passed to kernel?
by ckim＠etri.re.kr Jan. 4, 2021

Jan. 4, 2021

Hello, The APCI spec says "During OS initialization, OSPM must obtain the Root System Description Pointer (RSDP) structure from the platform. When OSPM locates the Root System Description Pointer (RSDP) structure, it then locates the Root System Description Table (RSDT) or the Extended Root System Description Table (XSDT) using the physical system address supplied in the RSDP." How does the bootloader pass the RSDP to the kernel? What is the most typical method and other options? I remember reading somewhere when it's using UEFI, the value is passed through UEFI system table or like that. I would appreciate if it's just a simple explanation. (though I'm more interested in UEFI case) Thank you. Chan Kim

1 0

Failure debug messages
by jim.cromie＠gmail.com Jan. 3, 2021

Jan. 3, 2021

So Im seeing these pr_debug messages from kernel/module.c [ 624.888832] dyndbg: 336 debug prints in module i915 [ 624.891526] module:find_symbol: Failed to find symbol i915_gpu_busy [ 624.891528] module:find_symbol: Failed to find symbol i915_gpu_lower [ 624.891530] module:find_symbol: Failed to find symbol i915_gpu_raise [ 624.891532] module:find_symbol: Failed to find symbol i915_gpu_turbo_disable [ 624.891534] module:find_symbol: Failed to find symbol i915_read_mch_val [ 624.891537] module:find_symbol: Failed to find symbol intel_gvt_register_hypervisor [ 624.891539] module:find_symbol: Failed to find symbol intel_gvt_unregister_hypervisor Best I can tell (from local experience, running this kernel) this is not a big-time hard failure. But what is going on? they all appear by name to be functions, not data

1 0