November 2024 - kernelnewbies@kernelnewbies.org

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

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

Ext4 reflink
by Racz Zoli Nov. 2, 2024

Nov. 2, 2024

Hey, I`m trying to implement "cp --reflink" in the ext4 filesystem but considering the lack of the documentation it`s not that easy. If somebody is interested in joining me with this, please let me know. Thanks.

1 0