December 2024 - kernelnewbies@kernelnewbies.org

Need help finding updated addresses
by Leam Hall Dec. 26, 2024

Dec. 26, 2024

Hey all, I was updating a KernelNewbies page, and wanted to let the original authors and contributors know. However, three of the email addresses bounced. Does anyone have current contact info for (old addresses listed): - Michal Piotrowski (michal.k.k.piotrowski(a)gmail.com) - Jarek Poplawski (jarkao2(a)o2.pl) - Mariusz Kozlowski (m.kozlowski(a)tuxland.pl) The page I edited: - https://kernelnewbies.org/Linux_Kernel_Tester's_Guide Thanks! Leam -- Linux Software Engineer (reuel.net/resume) Scribe: The Domici War (domiciwar.net) Coding Ne'er-do-well (github.com/LeamHall) Between "can" and "can't" is a gap of "I don't know", a place of discovery. For the passionate, much of "can't" falls into "yet". -- lh Practice allows options and foresight. -- lh

1 0

userland process PID/TGID in the RPC layer
by sandro Dec. 20, 2024

Dec. 20, 2024

Hello everyone, I am currently working on my bachelor thesis and I have a question regarding PIDs/TGIDs in the sunrpc layer of the kernel. I was wondering if I can obtain the PID/TGID of the userland process that originally caused a RPC request to be transmitted, from within the RPC request itself. Here is what I did: With a BPF program I collect the following metrics from a tracepoint inside “xprt_request_transmit()” function defined in /net/sunrpc/xprt.c: 1. current task name 2. current PID/TGID as a return value of bpf_get_current_pid_tgid() 3. The TGID assigned in the tk_owner field of struct rpc_task. (Using: BPF_CORE_READ(rpc_rqst, rq_task, tk_owner)) From the sources I have learned that TGID from 3. is assigned in “rpc_init_task() function” defined in /net/sunrpc/sched.c: task->tk_owner = current->tgid; In the output of the BPF program I see records with the following entries for the above metrics: 1. "kworker/u389:3” 2. "PID": 455045, "TGID": 455045 3. "rpc_tk_owner_tgid": 3989219 Here, evidently, the thread that executes the "xprt_request_transmit()” differs from the one that assigned the rpc_tk_owner_tgid in “rpc_init_task()”. The latter was executed by the userland process. But there are also records like this: 1. "kworker/u128:4" 2. "PID": 1457360, "TGID": 1457360 3. "rpc_tk_owner_tgid": 1457360 Here, the kworker did both the jobs. Now to my questions: 1. What determines which thread executes rpc_init_task()? 2. How can I, with certainty, obtain the userland process’ PID/TGID from inside rpc_init_task() ? Thank you for your answers. Best regards, Sandro

1 0

Help Needed: Debugging Memory Corruption results GPF
by Muni Sekhar Dec. 19, 2024

Dec. 19, 2024

Hi all, I am encountering a memory corruption issue in the function msm_set_laddr() from the Slimbus MSM Controller driver source code. https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-sunfis… In msm_set_laddr(), one of the arguments is ea (enumeration address), which is a pointer to constant data. While testing, I observed strange behavior: The contents of the ea buffer get corrupted during a timeout scenario in the call to: timeout = wait_for_completion_timeout(&done, HZ); Specifically, the ea buffer's contents differ before and after the wait_for_completion_timeout() call, even though it's declared as a pointer to constant data (const u8 *ea). To debug this issue, I enabled KASAN, but it didn't reveal any memory corruption. After the buffer corruption, random memory allocations in other parts of the kernel occasionally result in a GPF crash. Here is the relevant part of the code: static int msm_set_laddr(struct slim_controller *ctrl, const u8 *ea, u8 elen, u8 laddr) { struct msm_slim_ctrl *dev = slim_get_ctrldata(ctrl); struct completion done; int timeout, ret, retries = 0; u32 *buf; retry_laddr: init_completion(&done); mutex_lock(&dev->tx_lock); buf = msm_get_msg_buf(dev, 9, &done); if (buf == NULL) return -ENOMEM; buf[0] = SLIM_MSG_ASM_FIRST_WORD(9, SLIM_MSG_MT_CORE, SLIM_MSG_MC_ASSIGN_LOGICAL_ADDRESS, SLIM_MSG_DEST_LOGICALADDR, ea[5] | ea[4] << 8); buf[1] = ea[3] | (ea[2] << 8) | (ea[1] << 16) | (ea[0] << 24); buf[2] = laddr; ret = msm_send_msg_buf(dev, buf, 9, MGR_TX_MSG); timeout = wait_for_completion_timeout(&done, HZ); if (!timeout) dev->err = -ETIMEDOUT; if (dev->err) { ret = dev->err; dev->err = 0; } mutex_unlock(&dev->tx_lock); if (ret) { pr_err("set LADDR:0x%x failed:ret:%d, retrying", laddr, ret); if (retries < INIT_MX_RETRIES) { msm_slim_wait_retry(dev); retries++; goto retry_laddr; } else { pr_err("set LADDR failed after retrying:ret:%d", ret); } } return ret; } What I've Tried: KASAN: Enabled it but couldn't identify the source of the corruption. Debugging Logs: Added logs to print the ea contents before and after the wait_for_completion_timeout() call. The logs show a mismatch in the data. Question: How can I efficiently trace the source of the memory corruption in this scenario? Could wait_for_completion_timeout() or a related function cause unintended side effects? Are there additional tools or techniques (e.g., dynamic debugging or specific kernel config options) that can help identify this corruption? Any insights or suggestions would be greatly appreciated! -- Thanks, Sekhar

2 1

Abandoned patch
by Patryk Dec. 19, 2024

Dec. 19, 2024

Hi, I've got a question - what can I do with a patch that was submitted some time ago (about a year ago) but after the review was abandoned by the author for no obvious reason? Perhaps, the author did not have time to finalize upstream and started working on something else. Can I take such a patch, clean up according to the comments and send it again? If so, how can I provide / retain the information about the original patch author? This patch still seems to be useful as it adds the support for a device that is still in production. Moreover, I will probably need this patch in my project. Will be grateful for some advice. Best regards Patryk

2 1

Training: Semantic Patching of C and C++ Code with Coccinelle
by Michele Martone Dec. 17, 2024

Dec. 17, 2024

Dear Linux Kernel Hackers, this pretty unusual on-site training at LRZ in Munich, Germany may be of interest to some you, despite the HPC context that motivated it. __________________________________________________________________________________ What: Introduction to Semantic Patching of C and C++ Programs with Coccinelle, or A language to update large swathes of C/C++ code with non-trivial changes (with emphasis on HPC-specific restructurings). Why: Code maintenance and porting to new CPUs/GPUs is difficult. This can help. When: Wednesday, January 22, 2025, 09:30 - 17:30 Where: Leibniz Supercomputing Centre, Garching near Munich, Germany (ON-SITE) Who: Dr. Michele Martone https://github.com/michelemartone Prerequisites: Good C/C++ knowledge; HPC experience recommended. __________________________________________________________________________________ Registration URL: ===> ---> https://tiny.badw.de/gsRkBW <--- <=== __________________________________________________________________________________ The maintenance of a large software project can be very demanding. External factors like evolving third-party software library APIs, or constantly changing hardware platforms might require significant code adaptions for the code to run efficiently, or to run at all. Failure in coping with this can lead to obsolescence, loss of performance, incompatibility, vendor lock-in, bugs. Have you ever wondered how to detect and manipulate specified C/C++ code constructs, be it for code analysis, or better, to restructure an arbitrarily large codebase according to a specified, non-trivial `pattern', without writing a source-to-source translator yourself, but using an existing programmable one? In this training we introduce you to a tool to do exactly this: match and restructure code in a programmatic, formal way. After this training, you shall be able to write your own code transformations, be it for a refactoring, performance improvement, paving the way to an experimental fork, or for debug/analysis reasons. The training will also show how to analyse code looking for interesting patterns (e.g. bugs), integrate your Python scripts to achieve the custom transformations you need, and leverage Coccinelle's increasing C++ support. Special mention will go to performance-oriented transformations, of interest of HPC practitioners. __________________________________________________________________________________ -- Dr. Michele Martone https://michelemartone.org Leibniz Supercomputing Centre (LRZ) High Performance Systems Division Boltzmannstrasse 1 D-85748 Garching bei Muenchen Germany () ASCII ribbon campaign - against HTML e-mail /\ - against proprietary attachments

1 0

Query Regarding UART Controller Device Driver in Linux Kernel
by Muni Sekhar Dec. 3, 2024

Dec. 3, 2024

Dear Linux Kernel Community, I hope this email finds you well. I need to work on the high speed UART controller driver in the Linux kernel, and I have a few questions that I would appreciate your guidance on: I understand that the Linux kernel tree contains multiple source code files related to UART controller device drivers. Could you please point me to the relevant source code paths for these drivers? What is the maximum supported UART baud rate in the current kernel driver's supports? For example, if the hardware supports high-speed baud rates (e.g., 12 Mbps), are there any specific design strategies or modifications needed in the driver to support such high speeds? Are there any user-space utilities available for testing UART interfaces in Linux? If so, could you kindly share details on these utilities or provide any resources that would be useful for testing? Thank you for your time and support. I look forward to your response. -- Thanks, Sekhar

2 3