- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Re: How to switch between installed kernel and developed kernel
by Valdis Klētnieks March 23, 2021

March 23, 2021

On Tue, 23 Mar 2021 16:37:13 +0200, you said: > I gave up for now and prepared bash script for removing the files, based on > the information in > https://www.cyberciti.biz/faq/debian-redhat-linux-delete-kernel-command/ > (see "A note about custom compiled Linux kernel" section). In my opinion, > if Makefile supports install, it should support uninstall as well. Well, here's the thing.. the just-built kernel tree know what it has to install because it was just built with that .config, and it knows what files it just built. But how is that 5.12-rc4 build supposed to know what to remove that belonged to a 5.9 kernel built with a different .config that the 5.12-rc4 used, and which potentially had more modules enabled than the current source tree? Bonus points for knowing how to figure out if the 5.9 kernel was installed via rpm or dpkg or opkg or 'make install', and whether the 'make install' invoked the system-supplied /sbin/installkernel script, or the user provided a variant that installed more/less/different files? Especially as you noted, that it's a 3 or 4 line bash script to remove the files. And you hopefully know what extra rpm/dkpg stuff you need to clean up....

1 0

Mismatch between tcp_output.c and tcp_fastopen.c in net/ipv4
by Navin P March 23, 2021

March 23, 2021

Hi, I've a question regarding bytes_received and bytes_sent. https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_output.c#L1385 In net/ipv4/tcp_output.c if (skb->len != tcp_header_size) { tcp_event_data_sent(tp, sk); tp->data_segs_out += tcp_skb_pcount(skb); tp->bytes_sent += skb->len - tcp_header_size; } https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_fastopen.c#L220 In net/ipv4/tcp_fastopen.c /* u64_stats_update_begin(&tp->syncp) not needed here, * as we certainly are not changing upper 32bit value (0) */ tp->bytes_received = skb->len; Above we miss tcp_header_size. 1. Shouldn't bytes_received be skb->len - tcp_header_size for consistency ? I'm not sure if skb->len - tcp_header_size is correct . 2. Should it not be skb->len - tcp_header_size - ip_header_size - skb->mac_len ? Can you please clarify on these ? Regards, Navin

1 0

kernel projects for students
by Muni Sekhar March 22, 2021

March 22, 2021

Hi all, What are some good Linux projects in kernel space for final year computer.science engineering students? Could someone help and share your ideas on this please. -- Thanks, Sekhar

3 2

picking the first patch
by Harsha Vardhan March 22, 2021

March 22, 2021

Hello team , Sorry for a vague question. So far I have spent a lot of time dreaming to be a kernel hacker without doing much , but I realised its geting too late and now I want to pick my first patch to work, I have decided to address the TODO at drivers/staging/grebus/TODO : " * Make pwm.c use the struct pwm_ops::apply instead of ::config, ::set_polarity, 4 ::enable and ::disable." To make sure this is a first good patch , I verified that there is traction for this driver recently. But I am not sure, let's say I change the code , how to test it ? Any thoughts on whether I should just do a checkpatch.pl change as my first patch ? Thanks Vardhan

4 4

question about ioport_map function
by ckim＠etri.re.kr March 22, 2021

March 22, 2021

Hello all >From what I understand, to map io ports to virtual memory, we should use request_region, ioport_map/unmap and ioread/write functions. These are for architectures having input, output machine instructions like x86, x86_64. And the return address of ioport_map is physical address. Is my understanding correct? Thanks! Chan Kim

1 1

Help filing bugs from crash reports and repro files.
by Machiry Aravind Kumar March 21, 2021

March 21, 2021

Hello all, We have modified the syzkaller a bit to be more effective at finding kernel bugs. Attached are the crashes along with a reproducer .c file. Any help in figuring out the underlying bug and submitting a patch is greatly appreciated! -Best, Aravind

2 2

are 1-wire devices "discoverable"?
by Trevor Woerner March 19, 2021

March 19, 2021

Hi, I just watched the amazing device tree presentation recently done by Thomas Petazzoni (from Bootlin) for ST[1]. During the presentation, which is amazing, by the way ;-), Thomas describes the 1-wire protocol as not being discoverable. I was recently playing with the DS18B20 temperature sensor, which uses the 1-wire bus.[2] In fact, I was playing with a bunch of different temperature sensors with a RaspberryPi, and then gave a talk at a local RaspberryPi Meetup group that I regularly attend.[3] My only experience with the 1-wire bus is with this one device, so maybe the details of how the DS18B20 work are specific to the DS18B20 and not the way 1-wire devices work in general? But my (humble) conclusion is that the 1-wire bus is discoverable (or at least quasi-discoverable). It's true that you do need a device tree overlay to tell the kernel that you want to use the 1-wire bus, and you have to tell the kernel which GPIO pin you want to use as the 1 wire, but after that, attaching DS18B20 devices to a running system works quite magically.[4] Each DS18B20 has a unique 64-bit number burned into it, the first 8 bits specify the device type (i.e. the DS18B20), the next 48 bits are a unique serial number, and the last 8 bits are a CRC of the previous 56 bits. Due to the inclusion of the 8-bit device type, when I plug a DS18B20 into my board, the kernel automatically creates a sysfs entry for it with a "temperature" file that I can read to obtain the temperature in Celcius. I don't know if that qualifies as "discoverable"? It's certainly a lot more discoverable than I2C or SPI, although maybe not quite as discoverable as, say, PCI. Specifying the 1 wire is not discoverable, but plugging 1-wire devices into my board is maybe something that could be described as discoverable? Best regards, Trevor [1] https://www.youtube.com/watch?v=a9CZ1Uk3OYQ [2] https://twoerner.blogspot.com/2020/12/temperature-readings-with-ds18b20-and… [3] https://twoerner.blogspot.com/2021/01/sensing-temperature-with-raspberrypi.… [4] https://twoerner.blogspot.com/2020/12/multiple-ds18b20-temperature-probes.h…

2 1

/sys/devices/system/cpu/possible is immutable?
by Junyeong Jeong March 18, 2021

March 18, 2021

Hello everyone :) I hope that kernelnewbies mailing list is a suitable place for asking my question. I wonder that possible-CPU-mask(/sys/devices/system/cpu/possible) can be changed after boot in some way or other. I read that it is fixed at boot time (https://elixir.bootlin.com/linux/v5.8/source/include/linux/cpumask.h#L50) But I am not convinced that it is really immutable even if some cgroup or virtualization magic is used. Let me account for why I am curious about it. Nowadays I am developing BPF library written in rust language. In order to call `bpf_lookup_elem()` to get values from BPF_MAP_TYPE_PERCPU_ARRAY in userspace, we need to know the correct number of per-cpu areas before calling it. Because an out-buffer for multiple per-cpu values should be allocated and passed to the `bpf_lookup_elem()`. But this process is strongly based on the assumption that the number of per-cpu area is always immutable. I am referring to /sys/devices/system/cpu/possible file to get to know the number of per-cpu areas. I don't know the better way for figuring out the number. What I am anxious about is that the number of per-cpu areas varies from time to time under some circumstances with cgroup or virtualization magic. So I checked some cgroup and virtualization ordinary use-cases which did not affect the possible-CPU-mask. -- 1. $ docker run --cpuset-cpus=0-3 -it ubuntu:20.10 bash This does not affect /sys/devices/system/cpu/possible at all. The value it contains is the same with the value of the host machine. 2. $ virsh setvcpus --current ubuntu20.10 5 Before starting guest OS, the number of maximum vCPU was set to 8 and current vCPU was set to 4. While guest OS is running, I changed the number of vCPU to 5. And _inside guest OS_, I enabled the new CPU by setting /sys/devices/system/cpu/cpu4/online to 1. But /sys/devices/system/cpu/possible of guest OS did not change as expected. -- While I was conducting some tests, I realized that it's not possible to prove the immutability of possible-CPU-mask using inductive method. Because there must be some corner cases that I can never imagine. Can anyone explain that possible-CPU-mask and the number of per-cpu areas never change after boot-time even by cgroup magic or some tricks from outside of hypervisors? Thanks, Junyeong

2 2

Device file not appearing
by Gregory Anders March 17, 2021

March 17, 2021

Hi all, I'm writing a char device driver and am having trouble getting the file to appear under /dev. This isn't my first rodeo: in fact, I've written a few other drivers in the past and they have all worked as expected. This driver is based on the source code of those other drivers, so I'm fairly confident I'm doing everything correctly. So I'm stumped and looking for help. Here is what I have in my init function: #define DRIVER_NAME "foo" static int __init mod_init(void) { dev_t devno; my_class = class_create(THIS_MODULE, DRIVER_NAME); ret = alloc_chrdev_region(&devno, 0, MAX_DEVICES, DRIVER_NAME); my_major = MAJOR(devno); ... } (Note that for brevity I'm omitting a lot of boilerplate/error handling, etc. But you can assume it's all there). My driver is also a network driver; in fact, it's *primarily* a network driver and it provides a char device file that is used to configure the hardware. I am creating the char device whenever the network device is first opened (e.g. 'netdev_open' below is the 'ndo_open' field of the 'struct netdev_ops'): struct private_data { struct cdev cdev; ... } static int netdev_open(struct net_device *dev) { struct private_data *priv = netdev_priv(dev); dev_t devno; int minor; struct device *d; minor = ida_alloc_max(&ida, MAX_DEVICES, GFP_KERNEL); devno = MKDEV(my_major, minor); cdev_init(&priv->cdev, &my_fops); cdev_add(&priv->cdev, devno, 1); /* This should create a device node with the same name as the * network interface, e.g. foo0 */ d = device_create(my_class, NULL, devno, priv, dev->name); if (IS_ERR(d)) { ... } ... } Again, I'm omitting the error checking for the sake of brevity, but it is there in the actual code. This function runs successfully and the network device is successfully opened. The 'device_create' function does not return an error, but there is nothing beneath /dev as I would expect. I'm really stumped here because everything I've been able to find online says that 'device_create' ought to create that device file. I can see my class under /sys/class/ and that directory contains a directory with the name of the device: $ ls -1 /sys/class/my_class/ foo0 so it looks like the char device *is* being created, there's just no corresponding entry under /dev. Anyway, I know that's a lot of info. If you've made it this far, thanks for reading. If you have any insight/advice/suggestions for me I'd greatly appreciate it! Thanks, Greg

2 7

is there an efficient module_is_builtin() test ?
by jim.cromie＠gmail.com March 17, 2021

March 17, 2021

Im trying to reduce memory used by internal tables built into DYNAMIC_DEBUG the main savings available is in the per pr_debug* callsite data: modname, filename, funcname. I have segregated those fields to a new __dyndbg_sites section, described by struct _ddebug_site, and now refd by new ptr in struct _ddebug That new ptr enlarges the memory footprint, so I want to replace it with an integer index into the section / array. Existing padding could hold the index. To use the index, I need &dyndbg_sites[], and that only works for builtin-module's callsites. For loaded modules, I can/have added a pointer to the section into module load_info, giving me the base I will need for the ! builtin branch. I just need a not expensive is-it-builtin (modref)

2 2