March 2021 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

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

help with linker script mods
by jim.cromie＠gmail.com March 17, 2021

March 17, 2021

so Im trying to constrain the linker to put ELF section pairs into contiguous chunks of memory. this is on top of: https://lore.kernel.org/lkml/20210316050801.2446401-1-jim.cromie@gmail.com/ The macro below works when used in vmlinux.lds.h, it does pack the sections as desired. but same macro, when reused in module.lds.h, fails. The version below links ok, but appears to absorb the __dyndbg* sections into the .data section, which works for vmlinux.lds.h, cuz there we use the __start/stop ___dyndbg* symbols to use the section. In contrast, for modules, I want to preserve the named sections as proper elf sections in the ko, so that loader picks them up and saves them into struct load-info Anyone got some deep linker-fu ? [jimc@frodo wk-next]$ git diff diff --git a/include/asm-generic/module.lds.h b/include/asm-generic/module.lds.h index f210d5c1b78b..4840f01a0828 100644 --- a/include/asm-generic/module.lds.h +++ b/include/asm-generic/module.lds.h @@ -4,7 +4,26 @@ /* * <asm/module.lds.h> can specify arch-specific sections for linking modules. - * Empty for the asm-generic header. + * DYNAMIC_DEBUG needs its header sections contiguous with its data sections. */ +#if defined(CONFIG_DYNAMIC_DEBUG) || \ + (defined(CONFIG_DYNAMIC_DEBUG_CORE) \ + && defined(DYNAMIC_DEBUG_MODULE)) +#define DYNAMIC_DEBUG_DATA() \ + . = ALIGN(8); \ + __start___dyndbg_sites = .; \ + KEEP(*(__dyndbg_sites .gnu.linkonce.dyndbg_site)) \ + __stop___dyndbg_sites = .; \ + __start___dyndbg = .; \ + KEEP(*(__dyndbg .gnu.linkonce.dyndbg)) \ + __stop___dyndbg = .; +#else +#define DYNAMIC_DEBUG_DATA() +#endif + +SECTIONS { + .data : { DYNAMIC_DEBUG_DATA() } +} + #endif /* __ASM_GENERIC_MODULE_LDS_H */

1 0

Device file not appearing
by Gregory Anders March 16, 2021

March 16, 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

1 0

Re: Kernelnewbies Digest, Vol 124, Issue 4
by Axios N March 16, 2021

March 16, 2021

Re: Contents of Kernelnewbies digest...

2 3

Re: [PATCH 05/15] staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_PM
by Fabio Aiuto March 16, 2021

March 16, 2021

On Tue, Mar 16, 2021 at 12:39:19PM +0100, Greg KH wrote: > On Mon, Mar 15, 2021 at 11:15:02AM +0100, Fabio Aiuto wrote: > > remove conditional code blocks checked by unused CONFIG_PM > > > > cleaning required in TODO file: > > > > find and remove code blocks guarded by never set CONFIG_FOO defines > > > > Signed-off-by: Fabio Aiuto <fabioaiuto83(a)gmail.com> > > --- > > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 -------- > > 1 file changed, 8 deletions(-) > > > > diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > > index 2ff71d001c07..5748e1c1a25c 100644 > > --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > > +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > > @@ -3198,14 +3198,6 @@ static void rtw_cfg80211_preinit_wiphy(struct adapter *padapter, struct wiphy *w > > wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL; > > wiphy->flags |= WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAVE_AP_SME; > > > > -#if defined(CONFIG_PM) > > - wiphy->max_sched_scan_reqs = 1; > > -#endif > > - > > -#if defined(CONFIG_PM) > > - wiphy->wowlan = &wowlan_stub; > > -#endif > > How this is "unused"? This is a real config option, did you just change > the logic here? > > thanks, > > greg k-h Hi Greg, ignore this patch. I missed that definition of PM config option. I dropped it off my own local repo. Thank you, fabio

1 0

Re: linux-kernel janitorial RFP: Mark static arrays as const
by Joe Perches March 8, 2021

March 8, 2021

On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote: > On 02/03/2021 18.42, Joe Perches wrote: > > Here is a possible opportunity to reduce data usage in the kernel. > > > > $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \ > > grep -v __initdata | \ > > wc -l > > 3250 > > > > Meaning there are ~3000 declarations of arrays with what appears to be > > file static const content that are not marked const. > > > > So there are many static arrays that could be marked const to move the > > compiled object code from data to text minimizing the total amount of > > exposed r/w data. > > You can add const if you like, but it will rarely change the generated > code. gcc is already smart enough to take a static array whose contents > are provably never modified within the TU and put it in .rodata: At least some or perhaps even most of the time, true, but the gcc compiler from v5 through at least v10 seems inconsistent about when it does the appropriate conversion. See the example I posted: https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.camel… It was a randomly chosen source file conversion btw, I had no prior knowledge of whether the text/data use would change. I'm unsure about clang consistently moving static but provably const arrays from data to text. I rarely use clang. At least for v11 it seems to be better though. I didn't try 10.1.

2 3