- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

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

Re: Kernelnewbies Digest, Vol 168, Issue 5
by Dudley Nov. 15, 2024

Nov. 15, 2024

Hi Sekhar, I’ve fixed memory corruption issues in the past by replacing the memory cards. Have you tried swapping them out to see if the cards are the problem? Sometimes, even software stress tests won’t catch the issue. You might also want to test the setup on a different device using the same driver—that can help pinpoint the problem. Hope this helps! Dudley On November 16, 2024 2:00:01 AM GMT+09:00, kernelnewbies-request(a)kernelnewbies.org wrote: >Send Kernelnewbies mailing list submissions to > kernelnewbies(a)kernelnewbies.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >or, via email, send a message with subject or body 'help' to > kernelnewbies-request(a)kernelnewbies.org > >You can reach the person managing the list at > kernelnewbies-owner(a)kernelnewbies.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Kernelnewbies digest..." > > >Today's Topics: > > 1. Help Needed: Debugging Memory Corruption results GPF (Muni Sekhar) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 15 Nov 2024 21:47:59 +0530 >From: Muni Sekhar <munisekharrms(a)gmail.com> >To: kernel-hardening(a)lists.openwall.com, kasan-dev > <kasan-dev(a)googlegroups.com>, LKML <linux-kernel(a)vger.kernel.org>, > kernelnewbies <kernelnewbies(a)kernelnewbies.org> >Subject: Help Needed: Debugging Memory Corruption results GPF >Message-ID: > <CAHhAz%2Bi%2B4iCn%2BDdh1YvuMn1v-PfJj72m6DcjRaY%2B3vx7wLhFsQ(a)mail.gmail.com> >Content-Type: text/plain; charset="UTF-8" > >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 > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Kernelnewbies mailing list >Kernelnewbies(a)kernelnewbies.org >https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > >------------------------------ > >End of Kernelnewbies Digest, Vol 168, Issue 5 >*********************************************

1 0

Replacing reset gpio with reset controller
by Patryk Nov. 14, 2024

Nov. 14, 2024

Hi, First of all, I'm not sure what would be the best mailing list to ask this question, so if you have an idea what would be a better choice then I would be grateful if you could direct me to the right place. In the board that I've been working on, apart from the main CPU we also have an Intel MAX10 FPGA which acts as a system controller. It has a lot of signals connected over the board that it supervises. Eg. We have a few i2c devices and most of them expose a reset pin. All these reset pins from these devices are connected to the FPGA which is responsible for triggering resets. Apart from that, we thought about implementing a reset controller driver in the kernel that would communicate with this FPGA and allow to trigger a reset on any device (that has its reset pin connected to FPGA of course). I've browsed through the drivers that I'll need to enable on our board, and most of them expect some kind of reset api that they use e.g. during probe. Most of them however expects the reset_gpio which in our case is not what we want, as all resets are managed by FPGA and all reset requests should go through it. I'm wondering - would it be possible (and what is even more important, would it make sense?) to implement a reset controller driver (perhaps there is already something similiar?), that for the consumer drivers (like some sensors and so on that currently use gpiod* calls) would still remain as gpio-like reset (so they would still use gpiod* calls), whereas under the hood the calls would be forwarded to FPGA? If not, the other option I see is to extend the functionality of the drives that we are going to use reset_controller consumer api). I would be grateful for some advice. Best regards Patryk

1 0

Kernel contribution
by Ragavendra Nov. 12, 2024

Nov. 12, 2024

hi all, My name is Ragavendra and I have about fifteen years of work experience in the IT industry mostly in web development. However I did diploma in embedded systems in CDAC in 2005 and have been using Linux since then. I submitted my first patch in 2015 and am planning to contribute again now for a while. I went over the emails in the mailing list for the last few weeks or months to see how I can contribute. As a result, I signed up in Coverity and found one issue I thought I can help is say with the `1585136 Uninitialized scalar variable`. //// diff --git a/drivers/clk/sophgo/clk-cv18xx-pll.c b/drivers/clk/sophgo/clk-cv18xx-pll.c index 29e24098bf5f..a39a14fc39c2 100644 --- a/drivers/clk/sophgo/clk-cv18xx-pll.c +++ b/drivers/clk/sophgo/clk-cv18xx-pll.c @@ -327,7 +327,8 @@ static int fpll_find_rate(struct cv1800_clk_pll *pll, static int fpll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) { struct cv1800_clk_pll *pll = hw_to_cv1800_clk_pll(hw); - u32 val, ssc_syn_set; + u32 val = 0; + u32 ssc_syn_set = 0; if (!fpll_is_factional_mode(pll)) return ipll_determine_rate(hw, req); fpll_find_rate(pll, &pll->pll_limit[2], req->best_parent_rate, &req->rate, &val, &ssc_syn_set); //// Here, I am assuming that the default value for u32 is 0, if not please let me know what it should be or how it is determined. I know if it is of type pointer, its value should be NULL. Another example I saw was like below, where the enum was initialized which I am assuming to be is based on context. //// diff --git a/drivers/cpufreq/amd-pstate-ut.c b/drivers/cpufreq/amd-pstate-ut.c index 24432bd78a5a39..d52f26d1ffbab1 100644 --- a/drivers/cpufreq/amd-pstate-ut.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…> +++ b/drivers/cpufreq/amd-pstate-ut.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…> @@ -267,7 +267,7 @@ static int amd_pstate_set_mode(enum amd_pstate_mode mode) static void amd_pstate_ut_check_driver(u32 index) { - enum amd_pstate_mode mode1, mode2; + enum amd_pstate_mode mode1, mode2 = AMD_PSTATE_DISABLE; int ret; //// -- Thanks & regards, Ragavendra BN

1 0

Thermal governor related help
by Anuz Pratap Singh Tomar Nov. 3, 2024

Nov. 3, 2024

Hi all, I am trying to modify bang_bang thermal governor The source code I have taken from here https://android.googlesource.com/kernel/common/+/15753588bcd4/drivers/therm… bang bang governor will switch fan on when temperature reaches "trip" temperature and turn the fan off when temperature falls below "trip - hysteresis temperature". These Properties are set in the device file. I am modifying it to operate in three modes, ON, 50% and 100% fan speed depending on the temperature. At 100% fan is noisy, so 50% offers a good compromise for a slightly hotter system but when the system is too hot a 100% fan should be acceptable. Here are the device entries "trips" are set for 70-65 and 65-70 degrees celsius. and cooling maps use fan with state 0, 1 and 2 which are OFF, 50% and 100% thermal-zones { cpu-thermal { trips { cpu_trip_low: active-low { temperature = <65000>; hysteresis = <5000>; type = "active"; }; cpu_trip_high: active-high { temperature = <70000>; hysteresis = <5000>; type = "active"; }; }; cooling-maps { map1 { cooling-device = <&fan 0 1>; trip = <&cpu_trip_low>; }; map2 { cooling-device = <&fan 1 2>; trip = <&cpu_trip_high>; }; }; }; }; The modified algorithm is --- drivers/thermal/gov_bang_bang.c 2024-11-02 05:54:17.385093959 +0000 +++ drivers/thermal/gov_bang_bang.c.orig 2024-11-02 06:09:31.108870820 +0000 @@ -13,6 +13,10 @@ #include "thermal_core.h" +#define FAN_OFF 0 +#define FAN_ON_50 1 +#define FAN_ON_100 2 + static void thermal_zone_trip_update(struct thermal_zone_device *tz, int trip) { int trip_temp, trip_hyst; @@ -32,29 +36,59 @@ trip_hyst); list_for_each_entry(instance, &tz->thermal_instances, tz_node) { + + unsigned long upper; + unsigned long lower; + if (instance->trip != trip) continue; + upper = instance->upper; + lower = instance->lower; + + dev_dbg(&instance->cdev->device,"instance state = %ld trip = %d lower = %ld upper= %ld\n", + instance->target, trip,lower, upper); + /* in case fan is in initial state, switch the fan off */ if (instance->target == THERMAL_NO_TARGET) - instance->target = 0; + instance->target = FAN_OFF; - /* in case fan is neither on nor off set the fan to active */ - if (instance->target != 0 && instance->target != 1) { - pr_warn("Thermal instance %s controlled by bang-bang has unexpected state: %ld\n", - instance->name, instance->target); - instance->target = 1; + /* + * In case fan is not off or running at 50/100% settings, set the fan to + * upper or 50%. + */ + if (instance->target != FAN_OFF && + instance->target != FAN_ON_50 && + instance->target != FAN_ON_100) { + pr_warn("Thermal instance %s controlled by bang-bang has" + " unexpected state: %ld\n lower=%ld upper=%ld", + instance->name, instance->target, + lower, upper); + + if(upper > FAN_ON_100 || lower > FAN_ON_100) + instance->target = FAN_ON_50; + else + instance->target = upper; } /* - * enable fan when temperature exceeds trip_temp and disable - * the fan in case it falls below trip_temp minus hysteresis + * set fan to upper when temperature exceeds trip_temp and set + * fan to lower in case it falls below trip_temp minus hysteresis */ - if (instance->target == 0 && tz->temperature >= trip_temp) - instance->target = 1; - else if (instance->target == 1 && - tz->temperature <= trip_temp - trip_hyst) - instance->target = 0; + if (instance->target < upper && tz->temperature >= trip_temp) { + dev_dbg(&instance->cdev->device, "increase cooling: target" + " = %ld, upper = %ld, temp = %ld\n, trip_temp = %ld\n", + instance->target, upper tz->temperature trip_temp); + instance->target = upper; + + } else if (instance->target > lower && + tz->temperature <= trip_temp - trip_hyst) { + dev_dbg(&instance->cdev->device, "increase cooling: target" + " = %ld, lower = %ld, temp = %ld\n, trip_temp - hyst = %ld\n", + instance->target, lower, tz->temperature, + trip_temp - trip_hyst); + instance->target = lower; + } dev_dbg(&instance->cdev->device, "target=%d\n", (int)instance->target); What I have observed When temperature goes up from 60-65, the fan is switched on at 50%, and when temperature goes on from 65-70, fan is switched on at 100%. When the temperature goes down from 70-65, the fan goes from 100% to 50%, but it doesn't switch off when the temperature goes from 65-60. Fan stays running at 50% when temperature has fallen below the "trip - hysteresis" point. I put some debugs around the code to see what is happening. I observed that "instance->target" is showing two values 0 and 1, which are OFF and 50%, when I expect it to be OFF. My guess is these values are for different trips, since "trip2" has a "lower" set to 1. I am not quite sure how to make sure that value goes back 0 here. Any insight on what I have done wrong and what can I do to make it work? -- Thank you Warm Regards Anuz

1 0