August 2020 - kernelnewbies@kernelnewbies.org

cpu-freq: running the perf increases the data rate?
by Subhashini Rao Beerisetty Aug. 28, 2020

Aug. 28, 2020

[ Please keep me in CC as I'm not subscribed to the list] Hi all, I have an application which finds the data rate over the PCIe interface. I’m getting the lesser data rate in one of my Linux X86 systems. When I change the scaling_governor from "powersave" to "performance" mode for each CPU, then there is slight improvement in the PCIe data rate. Parallely I started profiling the workload with perf. Whenever I start running the profile command “perf stat -a -d -p <PID>” surprisingly the application resulted in excellent data rate over PCIe, but when I kill the perf command again PCIe data rate drops. I am really confused about this behavior.Any clues from this behaviour? Also I noticed my system not having the 'cpuinfo_cur_freq' sys file. Is that okay? cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory -- Thanks,

2 1

Scheduler benchmarks
by Muni Sekhar Aug. 25, 2020

Aug. 25, 2020

Hi all, I’ve two identical Linux systems with only kernel differences. While doing kernel profiling with perf, I got the below mentioned metrics for Scheduler benchmarks. 1st system (older kernel version compared to the other system) benchmark result: $ perf bench sched messaging -g 64 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 64 groups == 2560 processes run Total time: 2.936 [sec] 2nd system benchmark result: $ perf bench sched messaging -g 64 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 64 groups == 2560 processes run Total time: 10.074 [sec] So as per scheduler benchmark results, clearly a huge difference between two systems. Can anyone suggest to me how to dive deeper to know the root cause for it. Also are there any tunable kernel parameters related to this one? -- Thanks, Sekhar

4 8

Opening /proc/<pid>/net/dev prevents network namespace from expiring
by Arne Welzel Aug. 24, 2020

Aug. 24, 2020

Hello, as an unprivileged user one is able to keep network namespaces from expiring by opening /proc/<pid>/net/dev of other processes. I've previously put this on stackexchange [1] and then bugzilla [2]. That's been a while though, so posting here for a bit more visibility in case it's something that's worth fixing. The reproducer is roughly as follows. As root: # echo "100" > /proc/sys/user/max_net_namespaces # while true ; do (unshare -n bash -c 'sleep 0.3 && readlink /proc/self/ns/net') || sleep 0.5 ; done As unprivileged user in a second terminal, run the below Python script [3]: # python3 pin_net_namespaces.py After about one minute the first terminal will show the following until the Python process keeping the network namespaces alive is terminated. ... unshare: unshare failed: No space left on device unshare: unshare failed: No space left on device Without the change to max_net_namespaces reproducing just very long, but then also kernel memory grows fairly large. Does that seem like problematic behavior? I had attached a patch and tests to [2], but I fall into the kernel newbie category, so not sure how useful. Thanks, Arne [1] https://unix.stackexchange.com/questions/576718/opening-proc-pid-net-dev-pr… [2] https://bugzilla.kernel.org/show_bug.cgi?id=207351 [3] $ cat pin_net_namespaces.py #!/usr/bin/env python3 import glob import os import time net_namespaces = {} while True: for net_dev in glob.glob("/proc/*/net/dev"): try: ino = os.stat(net_dev).st_ino if ino not in net_namespaces: net_namespaces[ino] = open(net_dev) print("Have", len(net_namespaces), "namespaces...") except FileNotFoundError: # not fast enough... pass time.sleep(0.2) ===

3 2

How to pass flag from makefile to preprocesor when building external kernel module
by Tomek The Messenger Aug. 21, 2020

Aug. 21, 2020

Hi I have problem with passing flag from makefile to .c file. During building external kernel module my macro isn't seen by compiler. I used plenty of ways. First way: ccflags-y += -DMY_FLAG $(MAKE) -C $(KERNEL_SRC) M=$(SRC) Second: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) CFLAGS_my-kernel-module.o="-DMY_FLAG" Third: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) CFLAGS="-DMY_FLAG" Forth: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) ccflags-y="-DMY_FLAG" In general I use bitbake to build external kernel modules. And I wonder if bitbake doesn't introduce issue as some of above solution really should work. And additionally I had to use absolute paths in headers because relative didn't work so -I append also doesn't work: SRC := $(shell pwd) ccflags-y := -I$(SRC) BR Tomek

1 1

Validity of ioremap pointer within the kernel module
by Eduard Fuchs Aug. 19, 2020

Aug. 19, 2020

Hello, I am working on a driver for the McASP controller (on BeagleBone Black device) that works outside the sound subsystem. The following steps are performed correctly as far as I understand: * init() function of the module registers the "platform_driver" * Kernel finds the correct device in device-tree and performs the probe() function * in the probe() function, a "miscdevice" is created and the ressouce is mapped with devm_platform_ioremap_resource_byname() (address and size provided from dts). * in the probe() function, access to the McASP registers works without any problems. * the probe() function is left with "return 0". If at a later time, triggered by userspace, the open() function of "miscdevice" is called, then a kernel fault occurs: [ 1138.192489] DRV1: [drv_mdev_open():169]: misc device open called ... [ 1138.192517] misc testdrv: [drv_mdev_open():170]: memory for driver data found at 0xda9fca40 [ 1138.192526] misc testdrv: [drv_mdev_open():171]: virtual address for McASP registers base mapped at 0xFA038000. [ 1138.192532] DRV1: [mcasp_dump_registers():107]: Dump McASP register information: [ 1138.192538] 8<--- cut here --- [ 1138.195612] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa038000 [ 1138.203302] pgd = 13c9a0d5 [ 1138.206016] [fa038000] *pgd=48011452(bad) [ 1138.210048] Internal error: : 1028 [#1] PREEMPT THUMB2 [ 1138.215209] Modules linked in: testdrv1(O) ti_eqep counter spidev 8021q garp stp mrp llc evdev usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether libcomposite iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables [last unloaded: testdrv1] [ 1138.241265] CPU: 0 PID: 827 Comm: tesdrv_test Tainted: G O 5.7.6-tmc02 #1 [ 1138.249386] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1138.255518] PC is at mcasp_dump_registers+0x1a/0x338 [testdrv1] [ 1138.261463] LR is at mcasp_dump_registers+0x1b/0x338 [testdrv1] [ 1138.267404] pc : [<bf8a5086>] lr : [<bf8a5087>] psr: 60070033 [ 1138.273694] sp : dc133d60 ip : 00000000 fp : dc133e68 [ 1138.278936] r10: bf8a608c r9 : c0fb4c20 r8 : daee6030 [ 1138.284179] r7 : daeba000 r6 : 0000003d r5 : bf8a610c r4 : fa038000 [ 1138.290731] r3 : c0f05288 r2 : 00000000 r1 : 40070093 r0 : 00000044 [ 1138.297286] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 1138.304622] Control: 50c5387d Table: 98af4019 DAC: 00000051 [ 1138.310390] Process tesdrv_test (pid: 827, stack limit = 0xcf218d31) [ 1138.316769] Stack: (0xdc133d60 to 0xdc134000) [ 1138.321145] 3d60: c0f05288 da9fca44 bf8a610c 0000003d daeba000 bf8a553b fa038000 da9fca44 [ 1138.329359] 3d80: c0fb4c2c bf8a54e5 c0fb4c2c c0645d41 c0a7869c daee6030 dc351b80 daeba000 [ 1138.337572] 3da0: 00000000 dc0f3f00 dc351bac c0274d35 0000003d c0f05288 daeba000 daee6030 [ 1138.345786] 3dc0: 00000000 c0274ca9 daeba008 daeba000 dc133f18 c026d975 da2685d8 00000000 [ 1138.353999] 3de0: 00000000 00000002 00000000 00000000 daeba000 c027c815 00000002 dfdc34b4 [ 1138.362212] 3e00: dab8c800 00000000 00000000 c010ef31 8813a18f dc132000 8813a18f d8a35c00 [ 1138.370426] 3e20: 63c00000 00000041 8813a18f 00000002 daee6030 c0110e1f dc133edc c0f05288 [ 1138.378639] 3e40: 8813a18f daafc000 dc133f18 00000001 00000000 dc133f50 ffffff9c 00000005 [ 1138.386852] 3e60: 00000000 c027df4b db2279d0 da2685d8 7271e2e6 00000007 dc14a015 c0260183 [ 1138.395066] 3e80: 00000000 dbf154c8 daee6030 00000101 00000002 00000550 0000094c 00000000 [ 1138.403279] 3ea0: 00000000 00000000 dc133eac c026cb15 00000040 c0289997 dc0e6500 00000ff0 [ 1138.411493] 3ec0: ffffe000 004fe6ec 00000ff0 c0f05288 00000000 00000003 00000100 dc14a000 [ 1138.419706] 3ee0: 00000000 00000002 ffffff9c 00000000 dc1441ed 00000000 00000000 c0f05288 [ 1138.427919] 3f00: dc14a000 00000003 00000000 c026e1a1 00000000 c0f05288 00000000 dc130000 [ 1138.436132] 3f20: 00000004 00000100 00000001 c0f05288 d8a0f03c dc133f60 dc133f78 00000000 [ 1138.444346] 3f40: 00000000 00000000 00000000 c026f0bb 00000000 00000000 00000000 00000000 [ 1138.452559] 3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1138.460772] 3f80: 00000000 c0f05288 b6fdd000 bed70c38 00000000 00000000 00000005 c0100284 [ 1138.468986] 3fa0: dc132000 c0100061 bed70c38 00000000 004fe6ec 00000000 bed70d7c 004fe6ec [ 1138.477199] 3fc0: bed70c38 00000000 00000000 00000005 00000000 00000000 0050f000 00000000 [ 1138.485412] 3fe0: 00000000 bed70c04 004fe66b b6f59936 00070030 004fe6ec 00000000 00000000 [ 1138.493653] [<bf8a5086>] (mcasp_dump_registers [testdrv1]) from [<bf8a5087>] (mcasp_dump_registers+0x1b/0x338 [testdrv1]) [ 1138.504660] Code: f6cb 708a f0bc da0f (6822) 2100 [ 1138.509473] ---[ end trace bb0b2efe6c81b12a ]--- Does anyone have an idea that I forgot or do wrong. Thanks, Eduard Fuchs

1 0

Does "i_mutex" in comments mean inode_lock() in code ?
by Thomas Schmitt Aug. 18, 2020

Aug. 18, 2020

Hi, is function inode_lock() the thing which controls what lots of comments call "i_mutex" ? I am in particular riddling over this comment in include/linux/fs.h : /* * NOTE: unlike i_size_read(), i_size_write() does need locking around it * (normally i_mutex), otherwise on 32bit/SMP an update of i_size_seqcount * can be lost, resulting in subsequent i_size_read() calls spinning forever. */ because i cannot find any example in the git tree by grep -r mutex_unlock'.*[^a-z]'i_mutex . and the same for mutex_lock or mutex_trylock. But i see lots of comments mentioning an "i_mutex" structure element by grep -r '.*->'i_mutex . The nearest discovery to what i search for is in include/linux/fs.h static inline void inode_lock(struct inode *inode) It has lots of call instances in the code. But in contrast to "->imutex" i found not a glimpse of documentation. (Well it has enough room to hide from me ...) So is this the call by which i can reserve a cdrom device file inode before i call i_size_write() ? If so, shouldn't the comment in fs.h be "... (normally inode_lock) ..." ? Have a nice day :) Thomas

1 0

Help to test the powerpc architecture
by Oscar Carter Aug. 11, 2020

Aug. 11, 2020

Hi, I'm working in a new feature for the powerpc (64 bits little endian) architecture. Since I can't test it in a real environment, I need to emulate this arch. To do this I use qemu-ppc. My problem is that the built kernel don't boot in qemu. To build the kernel: make defconfig ARCH=powerpc Then I set to NO the CONFIG_KEXEC option as I found that qemu can't boot a KEXEC kernel. And now: make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 Finally I obtain a zImage in arch/powerpc/boot/ directory. Before to run qemu I create a rootfs with debootstrap. Then I run qemu with the following parameters: qemu-system-ppc -kernel /media/ubuntu/Data/linux/arch/powerpc/boot/zImage \ -append "root=/dev/sda console=ttyS0" \ -drive file=qemu_image.img,index=0,media=disk,format=raw \ --nographic If I add the "-prom-env boot-args=-v" to the end of the last command I get the same result. The qemu always stops at this point: >> ============================================================= >> OpenBIOS 1.1 [Dec 27 2018 23:11] >> Configuration device id QEMU version 1 machine id 2 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 27 2018 23:11 >> [ppc] Kernel already loaded (0x01000000 + 0x009085d8) (initrd 0x00000000 + 0x00000000) >> [ppc] Kernel command line: root=/dev/sda console=ttyS0 >> switching to new context: Also, I've tried to build the kernel with a DTB embedded in the image, but not luck. The same result again. make ps3_defconfig ARCH=powerpc make ARCH=powerpc simpleImage.ps3 CROSS_COMPILE=powerpc-linux-gnu- -j4 I'm stuck at this point. I don't know how to configure the kernel to be able to boot with qemu. Any help to point me to the right direction will be greatly appreciated. Thank's in advance. Oscar Carter

3 2

functions with empty body in file /kernel/events/core
by cristian andres vargas gonzalez Aug. 8, 2020

Aug. 8, 2020

2 1

delayed_put_task_struct() used by put_task_struct_rcu_user() never gets called
by William Tambe Aug. 8, 2020

Aug. 8, 2020

I am seeing an issue in my kernel where delayed_put_task_struct() used by put_task_struct_rcu_user() never gets called, resulting in a memory leak. Any idea ?

1 0

what are all the .cold symbols in system.map?
by jim.cromie＠gmail.com Aug. 8, 2020

Aug. 8, 2020

Ive been seeing these in my backtraces they seem to come in both .cold and not cold flavors are they related to unlikely() code blocks ? ffffffff81001820 t calibrate_delay_direct ffffffff81001a90 t calibrate_delay_converge ffffffff81001bb0 W calibration_delay_done ffffffff81001bc0 T calibrate_delay ffffffff81001cc3 t calibrate_delay_direct.cold ffffffff81001df7 t calibrate_delay.cold

1 0