* [ISSUE] Memleak in LED sysfs on heavy usage
@ 2016-09-12 8:50 ` Daniel Gorsulowski
2016-09-13 7:16 ` Jacek Anaszewski
2016-09-16 7:31 ` Jacek Anaszewski
0 siblings, 2 replies; 15+ messages in thread
From: Daniel Gorsulowski @ 2016-09-12 8:50 UTC (permalink / raw)
To: linux-leds; +Cc: linux-kernel
Hello!
Please consider if I made something wrong, sending this issue. This is
my first contact to the LKML.
By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
an user application. I figured out, that the free user memory decreased
constantly. So I tried to analyze the Problem and wrote a litte script:
#!/bin/sh
while [ 1 ]; do
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness
done
And voila, I was able to reproduce the problem.
So I add a bit more debugging:
#!/bin/sh
cnt=0
while [ 1 ]; do
if [ `expr $cnt % 1000` -eq 0 ]; then
free | grep Mem: | cut -d' ' -f25
fi
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness
let "cnt++"
done
And huh? No memory is eaten anymore. So it looks like, the problem only
occours on heavy (fast) usage of /sys/class/leds subsystem.
I rewrote the script and toggled a GPIO pin, but there was no problem
recognizable.
Some details about my test environment:
Hardware: Ti Sitara AM3357ZCZ with 128MiB memory
Kernel: vanilla 4.6
The relevant part of my .dts:
#include "am33xx.dtsi"
/ {
...
cpus {
cpu@0 {
cpu0-supply = <&dcdc2_reg>;
operating-points = <
/* kHz uV */
800000 1300000
600000 1112000
300000 969000
>;
};
};
memory {
device_type = "memory";
reg = <0x80000000 0x08000000>; /* 128 Mib */
};
...
leds {
pinctrl-names = "default";
pinctrl-0 = <&user_leds_s0>;
compatible = "gpio-leds";
...
led2 {
label = "2a_service_yellow";
gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "2a_service_yellow";
default-state = "off";
};
...
};
...
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&gpio_misc_pins>;
...
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
...
0x24 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (T10) gpmc_ad9.gpio0[23] */
>;
};
...
};
...
Kind regards
Daniel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-12 8:50 ` [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski
@ 2016-09-13 7:16 ` Jacek Anaszewski
2016-09-16 7:31 ` Jacek Anaszewski
1 sibling, 0 replies; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-13 7:16 UTC (permalink / raw)
To: Daniel Gorsulowski, linux-leds; +Cc: linux-kernel
Hi Daniel,
On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
> Hello!
>
> Please consider if I made something wrong, sending this issue. This is
> my first contact to the LKML.
> By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
> an user application. I figured out, that the free user memory decreased
> constantly. So I tried to analyze the Problem and wrote a litte script:
>
> #!/bin/sh
> while [ 1 ]; do
> echo 1 > /sys/class/leds/2a_service_yellow/brightness
> echo 0 > /sys/class/leds/2a_service_yellow/brightness
> done
>
> And voila, I was able to reproduce the problem.
> So I add a bit more debugging:
>
> #!/bin/sh
> cnt=0
> while [ 1 ]; do
> if [ `expr $cnt % 1000` -eq 0 ]; then
> free | grep Mem: | cut -d' ' -f25
> fi
> echo 1 > /sys/class/leds/2a_service_yellow/brightness
> echo 0 > /sys/class/leds/2a_service_yellow/brightness
> let "cnt++"
> done
>
> And huh? No memory is eaten anymore. So it looks like, the problem only
> occours on heavy (fast) usage of /sys/class/leds subsystem.
>
> I rewrote the script and toggled a GPIO pin, but there was no problem
> recognizable.
>
>
> Some details about my test environment:
> Hardware: Ti Sitara AM3357ZCZ with 128MiB memory
> Kernel: vanilla 4.6
>
> The relevant part of my .dts:
> #include "am33xx.dtsi"
>
> / {
> ...
> cpus {
> cpu@0 {
> cpu0-supply = <&dcdc2_reg>;
> operating-points = <
> /* kHz uV */
> 800000 1300000
> 600000 1112000
> 300000 969000
> >;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x80000000 0x08000000>; /* 128 Mib */
> };
> ...
>
> leds {
> pinctrl-names = "default";
> pinctrl-0 = <&user_leds_s0>;
>
> compatible = "gpio-leds";
>
> ...
> led2 {
> label = "2a_service_yellow";
> gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> linux,default-trigger = "2a_service_yellow";
> default-state = "off";
> };
>
> ...
> };
> ...
> };
>
> &am33xx_pinmux {
> pinctrl-names = "default";
> pinctrl-0 = <&gpio_misc_pins>;
>
> ...
> user_leds_s0: user_leds_s0 {
> pinctrl-single,pins = <
> ...
> 0x24 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (T10)
> gpmc_ad9.gpio0[23] */
> >;
> };
> ...
> };
> ...
Thanks for the report, I'll look into it.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-12 8:50 ` [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski
2016-09-13 7:16 ` Jacek Anaszewski
@ 2016-09-16 7:31 ` Jacek Anaszewski
2016-09-16 8:15 ` Daniel Gorsulowski
1 sibling, 1 reply; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 7:31 UTC (permalink / raw)
To: Daniel Gorsulowski, linux-leds; +Cc: linux-kernel
Hi Daniel,
On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
> Hello!
>
> Please consider if I made something wrong, sending this issue. This is
> my first contact to the LKML.
> By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
> an user application. I figured out, that the free user memory decreased
> constantly. So I tried to analyze the Problem and wrote a litte script:
>
> #!/bin/sh
> while [ 1 ]; do
> echo 1 > /sys/class/leds/2a_service_yellow/brightness
> echo 0 > /sys/class/leds/2a_service_yellow/brightness
> done
>
> And voila, I was able to reproduce the problem.
> So I add a bit more debugging:
>
> #!/bin/sh
> cnt=0
> while [ 1 ]; do
> if [ `expr $cnt % 1000` -eq 0 ]; then
> free | grep Mem: | cut -d' ' -f25
> fi
> echo 1 > /sys/class/leds/2a_service_yellow/brightness
> echo 0 > /sys/class/leds/2a_service_yellow/brightness
> let "cnt++"
> done
>
> And huh? No memory is eaten anymore. So it looks like, the problem only
> occours on heavy (fast) usage of /sys/class/leds subsystem.
>
> I rewrote the script and toggled a GPIO pin, but there was no problem
> recognizable.
I've been unable to reproduce the problem with leds-aat1290 driver
and Samsung M0 board. It must be driver specific issue.
What driver did you use?
>
> Some details about my test environment:
> Hardware: Ti Sitara AM3357ZCZ with 128MiB memory
> Kernel: vanilla 4.6
>
> The relevant part of my .dts:
> #include "am33xx.dtsi"
>
> / {
> ...
> cpus {
> cpu@0 {
> cpu0-supply = <&dcdc2_reg>;
> operating-points = <
> /* kHz uV */
> 800000 1300000
> 600000 1112000
> 300000 969000
> >;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x80000000 0x08000000>; /* 128 Mib */
> };
> ...
>
> leds {
> pinctrl-names = "default";
> pinctrl-0 = <&user_leds_s0>;
>
> compatible = "gpio-leds";
>
> ...
> led2 {
> label = "2a_service_yellow";
> gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> linux,default-trigger = "2a_service_yellow";
> default-state = "off";
> };
>
> ...
> };
> ...
> };
>
> &am33xx_pinmux {
> pinctrl-names = "default";
> pinctrl-0 = <&gpio_misc_pins>;
>
> ...
> user_leds_s0: user_leds_s0 {
> pinctrl-single,pins = <
> ...
> 0x24 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (T10)
> gpmc_ad9.gpio0[23] */
> >;
> };
> ...
> };
> ...
>
> Kind regards
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 7:31 ` Jacek Anaszewski
@ 2016-09-16 8:15 ` Daniel Gorsulowski
2016-09-16 11:25 ` Jacek Anaszewski
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Gorsulowski @ 2016-09-16 8:15 UTC (permalink / raw)
To: Jacek Anaszewski, linux-leds; +Cc: linux-kernel
Hi Jacek,
Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
> Hi Daniel,
>
> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>> Hello!
>>
>> Please consider if I made something wrong, sending this issue. This is
>> my first contact to the LKML.
>> By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
>> an user application. I figured out, that the free user memory decreased
>> constantly. So I tried to analyze the Problem and wrote a litte script:
>>
>> #!/bin/sh
>> while [ 1 ]; do
>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>> done
>>
>> And voila, I was able to reproduce the problem.
>> So I add a bit more debugging:
>>
>> #!/bin/sh
>> cnt=0
>> while [ 1 ]; do
>> if [ `expr $cnt % 1000` -eq 0 ]; then
>> free | grep Mem: | cut -d' ' -f25
>> fi
>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>> let "cnt++"
>> done
>>
>> And huh? No memory is eaten anymore. So it looks like, the problem only
>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>
>> I rewrote the script and toggled a GPIO pin, but there was no problem
>> recognizable.
>
> I've been unable to reproduce the problem with leds-aat1290 driver
> and Samsung M0 board. It must be driver specific issue.
> What driver did you use?
>
I defined LEDS_GPIO and so I'm using leds-gpio driver.
danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
-v "^# "
CONFIG_INPUT_LEDS=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>
>> Some details about my test environment:
>> Hardware: Ti Sitara AM3357ZCZ with 128MiB memory
>> Kernel: vanilla 4.6
>>
>> The relevant part of my .dts:
>> #include "am33xx.dtsi"
>>
>> / {
>> ...
>> cpus {
>> cpu@0 {
>> cpu0-supply = <&dcdc2_reg>;
>> operating-points = <
>> /* kHz uV */
>> 800000 1300000
>> 600000 1112000
>> 300000 969000
>> >;
>> };
>> };
>>
>> memory {
>> device_type = "memory";
>> reg = <0x80000000 0x08000000>; /* 128 Mib */
>> };
>> ...
>>
>> leds {
>> pinctrl-names = "default";
>> pinctrl-0 = <&user_leds_s0>;
>>
>> compatible = "gpio-leds";
>>
>> ...
>> led2 {
>> label = "2a_service_yellow";
>> gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
>> linux,default-trigger = "2a_service_yellow";
>> default-state = "off";
>> };
>>
>> ...
>> };
>> ...
>> };
>>
>> &am33xx_pinmux {
>> pinctrl-names = "default";
>> pinctrl-0 = <&gpio_misc_pins>;
>>
>> ...
>> user_leds_s0: user_leds_s0 {
>> pinctrl-single,pins = <
>> ...
>> 0x24 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (T10)
>> gpmc_ad9.gpio0[23] */
>> >;
>> };
>> ...
>> };
>> ...
>>
>> Kind regards
>> Daniel
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 8:15 ` Daniel Gorsulowski
@ 2016-09-16 11:25 ` Jacek Anaszewski
2016-09-16 12:08 ` Daniel Gorsulowski
0 siblings, 1 reply; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 11:25 UTC (permalink / raw)
To: Daniel Gorsulowski, linux-leds; +Cc: linux-kernel
On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
> Hi Jacek,
>
> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>> Hi Daniel,
>>
>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>> Hello!
>>>
>>> Please consider if I made something wrong, sending this issue. This is
>>> my first contact to the LKML.
>>> By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
>>> an user application. I figured out, that the free user memory decreased
>>> constantly. So I tried to analyze the Problem and wrote a litte script:
>>>
>>> #!/bin/sh
>>> while [ 1 ]; do
>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>> done
>>>
>>> And voila, I was able to reproduce the problem.
>>> So I add a bit more debugging:
>>>
>>> #!/bin/sh
>>> cnt=0
>>> while [ 1 ]; do
>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>> free | grep Mem: | cut -d' ' -f25
>>> fi
>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>> let "cnt++"
>>> done
>>>
>>> And huh? No memory is eaten anymore. So it looks like, the problem only
>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>
>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>> recognizable.
>>
>> I've been unable to reproduce the problem with leds-aat1290 driver
>> and Samsung M0 board. It must be driver specific issue.
>> What driver did you use?
>>
> I defined LEDS_GPIO and so I'm using leds-gpio driver.
> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
> -v "^# "
> CONFIG_INPUT_LEDS=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_TIMER=y
> CONFIG_LEDS_TRIGGER_ONESHOT=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> CONFIG_LEDS_TRIGGER_GPIO=y
> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>
Unfortunately I am still unable to reproduce the problem with leds-gpio.
I'm not observing any heavy usage with your test case:
~#free
total used free shared buffers cached
Mem: 1028092 61364 966728 0 8416 22396
-/+ buffers/cache: 30552 997540
Swap: 0 0 0
Actually you didn't give any numbers. What kernel version are you using?
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 11:25 ` Jacek Anaszewski
@ 2016-09-16 12:08 ` Daniel Gorsulowski
2016-09-16 13:41 ` Jacek Anaszewski
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Gorsulowski @ 2016-09-16 12:08 UTC (permalink / raw)
To: Jacek Anaszewski, linux-leds; +Cc: linux-kernel
Hi Jacek,
Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>> Hi Jacek,
>>
>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>> Hi Daniel,
>>>
>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>> Hello!
>>>>
>>>> Please consider if I made something wrong, sending this issue. This is
>>>> my first contact to the LKML.
>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
>>>> an user application. I figured out, that the free user memory decreased
>>>> constantly. So I tried to analyze the Problem and wrote a litte script:
>>>>
>>>> #!/bin/sh
>>>> while [ 1 ]; do
>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>> done
>>>>
>>>> And voila, I was able to reproduce the problem.
>>>> So I add a bit more debugging:
>>>>
>>>> #!/bin/sh
>>>> cnt=0
>>>> while [ 1 ]; do
>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>> free | grep Mem: | cut -d' ' -f25
>>>> fi
>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>> let "cnt++"
>>>> done
>>>>
>>>> And huh? No memory is eaten anymore. So it looks like, the problem only
>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>
>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>> recognizable.
>>>
>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>> and Samsung M0 board. It must be driver specific issue.
>>> What driver did you use?
>>>
>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>> -v "^# "
>> CONFIG_INPUT_LEDS=y
>> CONFIG_NEW_LEDS=y
>> CONFIG_LEDS_CLASS=y
>> CONFIG_LEDS_GPIO=y
>> CONFIG_LEDS_TRIGGERS=y
>> CONFIG_LEDS_TRIGGER_TIMER=y
>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>> CONFIG_LEDS_TRIGGER_GPIO=y
>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>
>
> Unfortunately I am still unable to reproduce the problem with leds-gpio.
> I'm not observing any heavy usage with your test case:
>
> ~#free
> total used free shared buffers cached
> Mem: 1028092 61364 966728 0 8416 22396
> -/+ buffers/cache: 30552 997540
> Swap: 0 0 0
>
>
> Actually you didn't give any numbers. What kernel version are you using?
>
As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
kernel (with PREEMPT-RT Patchset).
Kind regards,
Daniel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 12:08 ` Daniel Gorsulowski
@ 2016-09-16 13:41 ` Jacek Anaszewski
2016-09-16 14:06 ` Greg KH
2016-09-19 4:35 ` Daniel Gorsulowski
0 siblings, 2 replies; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 13:41 UTC (permalink / raw)
To: Daniel Gorsulowski, linux-leds; +Cc: linux-kernel, Greg KH
On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
> Hi Jacek,
>
> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>> Hi Jacek,
>>>
>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>> Hi Daniel,
>>>>
>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>> Hello!
>>>>>
>>>>> Please consider if I made something wrong, sending this issue. This is
>>>>> my first contact to the LKML.
>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very
>>>>> fast in
>>>>> an user application. I figured out, that the free user memory
>>>>> decreased
>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>> script:
>>>>>
>>>>> #!/bin/sh
>>>>> while [ 1 ]; do
>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>> done
>>>>>
>>>>> And voila, I was able to reproduce the problem.
>>>>> So I add a bit more debugging:
>>>>>
>>>>> #!/bin/sh
>>>>> cnt=0
>>>>> while [ 1 ]; do
>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>> free | grep Mem: | cut -d' ' -f25
>>>>> fi
>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>> let "cnt++"
>>>>> done
>>>>>
>>>>> And huh? No memory is eaten anymore. So it looks like, the problem
>>>>> only
>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>
>>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>>> recognizable.
>>>>
>>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>>> and Samsung M0 board. It must be driver specific issue.
>>>> What driver did you use?
>>>>
>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>>> -v "^# "
>>> CONFIG_INPUT_LEDS=y
>>> CONFIG_NEW_LEDS=y
>>> CONFIG_LEDS_CLASS=y
>>> CONFIG_LEDS_GPIO=y
>>> CONFIG_LEDS_TRIGGERS=y
>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>
>>
>> Unfortunately I am still unable to reproduce the problem with leds-gpio.
>> I'm not observing any heavy usage with your test case:
>>
>> ~#free
>> total used free shared buffers
>> cached
>> Mem: 1028092 61364 966728 0 8416 22396
>> -/+ buffers/cache: 30552 997540
>> Swap: 0 0 0
>>
>>
>> Actually you didn't give any numbers. What kernel version are you using?
>>
> As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
> kernel (with PREEMPT-RT Patchset).
Heh, funny coincidence. I was testing this on recent linux-leds.git,
for-next branch and was not able to detect the issue. It started to
appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
that what fixes the issue is the most recent commit [1].
Further investigation revealed that this is kobject_uevent_env(),
called from led_trigger_set(), which causes memory leaks when called
with high frequency.
CC GregKH.
[1]
https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-leds.git/commit/?h=for-next&id=f3f624941be0fafb29fff5c1411fa433feca792c
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 13:41 ` Jacek Anaszewski
@ 2016-09-16 14:06 ` Greg KH
2016-09-16 14:32 ` Jacek Anaszewski
2016-09-19 4:35 ` Daniel Gorsulowski
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2016-09-16 14:06 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Daniel Gorsulowski, linux-leds, linux-kernel
On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
> > Hi Jacek,
> >
> > Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
> > > On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
> > > > Hi Jacek,
> > > >
> > > > Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
> > > > > Hi Daniel,
> > > > >
> > > > > On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
> > > > > > Hello!
> > > > > >
> > > > > > Please consider if I made something wrong, sending this issue. This is
> > > > > > my first contact to the LKML.
> > > > > > By mistake, I accessed an LED via /sys/class/leds subsystem very
> > > > > > fast in
> > > > > > an user application. I figured out, that the free user memory
> > > > > > decreased
> > > > > > constantly. So I tried to analyze the Problem and wrote a litte
> > > > > > script:
> > > > > >
> > > > > > #!/bin/sh
> > > > > > while [ 1 ]; do
> > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > done
> > > > > >
> > > > > > And voila, I was able to reproduce the problem.
> > > > > > So I add a bit more debugging:
> > > > > >
> > > > > > #!/bin/sh
> > > > > > cnt=0
> > > > > > while [ 1 ]; do
> > > > > > if [ `expr $cnt % 1000` -eq 0 ]; then
> > > > > > free | grep Mem: | cut -d' ' -f25
> > > > > > fi
> > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > let "cnt++"
> > > > > > done
> > > > > >
> > > > > > And huh? No memory is eaten anymore. So it looks like, the problem
> > > > > > only
> > > > > > occours on heavy (fast) usage of /sys/class/leds subsystem.
> > > > > >
> > > > > > I rewrote the script and toggled a GPIO pin, but there was no problem
> > > > > > recognizable.
> > > > >
> > > > > I've been unable to reproduce the problem with leds-aat1290 driver
> > > > > and Samsung M0 board. It must be driver specific issue.
> > > > > What driver did you use?
> > > > >
> > > > I defined LEDS_GPIO and so I'm using leds-gpio driver.
> > > > danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
> > > > -v "^# "
> > > > CONFIG_INPUT_LEDS=y
> > > > CONFIG_NEW_LEDS=y
> > > > CONFIG_LEDS_CLASS=y
> > > > CONFIG_LEDS_GPIO=y
> > > > CONFIG_LEDS_TRIGGERS=y
> > > > CONFIG_LEDS_TRIGGER_TIMER=y
> > > > CONFIG_LEDS_TRIGGER_ONESHOT=y
> > > > CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> > > > CONFIG_LEDS_TRIGGER_GPIO=y
> > > > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> > > > CONFIG_LEDS_TRIGGER_TRANSIENT=y
> > > >
> > >
> > > Unfortunately I am still unable to reproduce the problem with leds-gpio.
> > > I'm not observing any heavy usage with your test case:
> > >
> > > ~#free
> > > total used free shared buffers
> > > cached
> > > Mem: 1028092 61364 966728 0 8416 22396
> > > -/+ buffers/cache: 30552 997540
> > > Swap: 0 0 0
> > >
> > >
> > > Actually you didn't give any numbers. What kernel version are you using?
> > >
> > As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
> > kernel (with PREEMPT-RT Patchset).
>
> Heh, funny coincidence. I was testing this on recent linux-leds.git,
> for-next branch and was not able to detect the issue. It started to
> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
> that what fixes the issue is the most recent commit [1].
>
> Further investigation revealed that this is kobject_uevent_env(),
> called from led_trigger_set(), which causes memory leaks when called
> with high frequency.
Really? Where in kobject_uevent_env() is the memory leak?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 14:06 ` Greg KH
@ 2016-09-16 14:32 ` Jacek Anaszewski
2016-09-16 14:39 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 14:32 UTC (permalink / raw)
To: Greg KH; +Cc: Daniel Gorsulowski, linux-leds, linux-kernel
On 09/16/2016 04:06 PM, Greg KH wrote:
> On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
>> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
>>> Hi Jacek,
>>>
>>> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>>>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>>>> Hi Jacek,
>>>>>
>>>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> Please consider if I made something wrong, sending this issue. This is
>>>>>>> my first contact to the LKML.
>>>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very
>>>>>>> fast in
>>>>>>> an user application. I figured out, that the free user memory
>>>>>>> decreased
>>>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>>>> script:
>>>>>>>
>>>>>>> #!/bin/sh
>>>>>>> while [ 1 ]; do
>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>> done
>>>>>>>
>>>>>>> And voila, I was able to reproduce the problem.
>>>>>>> So I add a bit more debugging:
>>>>>>>
>>>>>>> #!/bin/sh
>>>>>>> cnt=0
>>>>>>> while [ 1 ]; do
>>>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>>>> free | grep Mem: | cut -d' ' -f25
>>>>>>> fi
>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>> let "cnt++"
>>>>>>> done
>>>>>>>
>>>>>>> And huh? No memory is eaten anymore. So it looks like, the problem
>>>>>>> only
>>>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>>>
>>>>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>>>>> recognizable.
>>>>>>
>>>>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>>>>> and Samsung M0 board. It must be driver specific issue.
>>>>>> What driver did you use?
>>>>>>
>>>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>>>>> -v "^# "
>>>>> CONFIG_INPUT_LEDS=y
>>>>> CONFIG_NEW_LEDS=y
>>>>> CONFIG_LEDS_CLASS=y
>>>>> CONFIG_LEDS_GPIO=y
>>>>> CONFIG_LEDS_TRIGGERS=y
>>>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>>>
>>>>
>>>> Unfortunately I am still unable to reproduce the problem with leds-gpio.
>>>> I'm not observing any heavy usage with your test case:
>>>>
>>>> ~#free
>>>> total used free shared buffers
>>>> cached
>>>> Mem: 1028092 61364 966728 0 8416 22396
>>>> -/+ buffers/cache: 30552 997540
>>>> Swap: 0 0 0
>>>>
>>>>
>>>> Actually you didn't give any numbers. What kernel version are you using?
>>>>
>>> As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
>>> kernel (with PREEMPT-RT Patchset).
>>
>> Heh, funny coincidence. I was testing this on recent linux-leds.git,
>> for-next branch and was not able to detect the issue. It started to
>> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
>> that what fixes the issue is the most recent commit [1].
>>
>> Further investigation revealed that this is kobject_uevent_env(),
>> called from led_trigger_set(), which causes memory leaks when called
>> with high frequency.
>
> Really? Where in kobject_uevent_env() is the memory leak?
I'll chase it down when and will let you know. This may be
non-trivial issue as it suffices to add "sleep 0.1" between
brightness setting operations to prevent it.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 14:32 ` Jacek Anaszewski
@ 2016-09-16 14:39 ` Greg KH
2016-09-16 18:49 ` Jacek Anaszewski
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2016-09-16 14:39 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Daniel Gorsulowski, linux-leds, linux-kernel
On Fri, Sep 16, 2016 at 04:32:39PM +0200, Jacek Anaszewski wrote:
> On 09/16/2016 04:06 PM, Greg KH wrote:
> > On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
> > > On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
> > > > Hi Jacek,
> > > >
> > > > Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
> > > > > On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
> > > > > > Hi Jacek,
> > > > > >
> > > > > > Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Please consider if I made something wrong, sending this issue. This is
> > > > > > > > my first contact to the LKML.
> > > > > > > > By mistake, I accessed an LED via /sys/class/leds subsystem very
> > > > > > > > fast in
> > > > > > > > an user application. I figured out, that the free user memory
> > > > > > > > decreased
> > > > > > > > constantly. So I tried to analyze the Problem and wrote a litte
> > > > > > > > script:
> > > > > > > >
> > > > > > > > #!/bin/sh
> > > > > > > > while [ 1 ]; do
> > > > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > done
> > > > > > > >
> > > > > > > > And voila, I was able to reproduce the problem.
> > > > > > > > So I add a bit more debugging:
> > > > > > > >
> > > > > > > > #!/bin/sh
> > > > > > > > cnt=0
> > > > > > > > while [ 1 ]; do
> > > > > > > > if [ `expr $cnt % 1000` -eq 0 ]; then
> > > > > > > > free | grep Mem: | cut -d' ' -f25
> > > > > > > > fi
> > > > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > let "cnt++"
> > > > > > > > done
> > > > > > > >
> > > > > > > > And huh? No memory is eaten anymore. So it looks like, the problem
> > > > > > > > only
> > > > > > > > occours on heavy (fast) usage of /sys/class/leds subsystem.
> > > > > > > >
> > > > > > > > I rewrote the script and toggled a GPIO pin, but there was no problem
> > > > > > > > recognizable.
> > > > > > >
> > > > > > > I've been unable to reproduce the problem with leds-aat1290 driver
> > > > > > > and Samsung M0 board. It must be driver specific issue.
> > > > > > > What driver did you use?
> > > > > > >
> > > > > > I defined LEDS_GPIO and so I'm using leds-gpio driver.
> > > > > > danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
> > > > > > -v "^# "
> > > > > > CONFIG_INPUT_LEDS=y
> > > > > > CONFIG_NEW_LEDS=y
> > > > > > CONFIG_LEDS_CLASS=y
> > > > > > CONFIG_LEDS_GPIO=y
> > > > > > CONFIG_LEDS_TRIGGERS=y
> > > > > > CONFIG_LEDS_TRIGGER_TIMER=y
> > > > > > CONFIG_LEDS_TRIGGER_ONESHOT=y
> > > > > > CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> > > > > > CONFIG_LEDS_TRIGGER_GPIO=y
> > > > > > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> > > > > > CONFIG_LEDS_TRIGGER_TRANSIENT=y
> > > > > >
> > > > >
> > > > > Unfortunately I am still unable to reproduce the problem with leds-gpio.
> > > > > I'm not observing any heavy usage with your test case:
> > > > >
> > > > > ~#free
> > > > > total used free shared buffers
> > > > > cached
> > > > > Mem: 1028092 61364 966728 0 8416 22396
> > > > > -/+ buffers/cache: 30552 997540
> > > > > Swap: 0 0 0
> > > > >
> > > > >
> > > > > Actually you didn't give any numbers. What kernel version are you using?
> > > > >
> > > > As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
> > > > kernel (with PREEMPT-RT Patchset).
> > >
> > > Heh, funny coincidence. I was testing this on recent linux-leds.git,
> > > for-next branch and was not able to detect the issue. It started to
> > > appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
> > > that what fixes the issue is the most recent commit [1].
> > >
> > > Further investigation revealed that this is kobject_uevent_env(),
> > > called from led_trigger_set(), which causes memory leaks when called
> > > with high frequency.
> >
> > Really? Where in kobject_uevent_env() is the memory leak?
>
> I'll chase it down when and will let you know. This may be
> non-trivial issue as it suffices to add "sleep 0.1" between
> brightness setting operations to prevent it.
Why are you abusing uevents for flashing an LED? Please don't do that,
it's not what that interface is for at all.
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 14:39 ` Greg KH
@ 2016-09-16 18:49 ` Jacek Anaszewski
2016-09-16 19:44 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 18:49 UTC (permalink / raw)
To: Greg KH, Jacek Anaszewski; +Cc: Daniel Gorsulowski, linux-leds, linux-kernel
On 09/16/2016 04:39 PM, Greg KH wrote:
> On Fri, Sep 16, 2016 at 04:32:39PM +0200, Jacek Anaszewski wrote:
>> On 09/16/2016 04:06 PM, Greg KH wrote:
>>> On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
>>>> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
>>>>> Hi Jacek,
>>>>>
>>>>> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>>>>>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>>>>>> Hi Jacek,
>>>>>>>
>>>>>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Please consider if I made something wrong, sending this issue. This is
>>>>>>>>> my first contact to the LKML.
>>>>>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very
>>>>>>>>> fast in
>>>>>>>>> an user application. I figured out, that the free user memory
>>>>>>>>> decreased
>>>>>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>>>>>> script:
>>>>>>>>>
>>>>>>>>> #!/bin/sh
>>>>>>>>> while [ 1 ]; do
>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>> done
>>>>>>>>>
>>>>>>>>> And voila, I was able to reproduce the problem.
>>>>>>>>> So I add a bit more debugging:
>>>>>>>>>
>>>>>>>>> #!/bin/sh
>>>>>>>>> cnt=0
>>>>>>>>> while [ 1 ]; do
>>>>>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>>>>>> free | grep Mem: | cut -d' ' -f25
>>>>>>>>> fi
>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>> let "cnt++"
>>>>>>>>> done
>>>>>>>>>
>>>>>>>>> And huh? No memory is eaten anymore. So it looks like, the problem
>>>>>>>>> only
>>>>>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>>>>>
>>>>>>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>>>>>>> recognizable.
>>>>>>>>
>>>>>>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>>>>>>> and Samsung M0 board. It must be driver specific issue.
>>>>>>>> What driver did you use?
>>>>>>>>
>>>>>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>>>>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>>>>>>> -v "^# "
>>>>>>> CONFIG_INPUT_LEDS=y
>>>>>>> CONFIG_NEW_LEDS=y
>>>>>>> CONFIG_LEDS_CLASS=y
>>>>>>> CONFIG_LEDS_GPIO=y
>>>>>>> CONFIG_LEDS_TRIGGERS=y
>>>>>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>>>>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>>>>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>>>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>>>>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>>>>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>>>>>
>>>>>>
>>>>>> Unfortunately I am still unable to reproduce the problem with leds-gpio.
>>>>>> I'm not observing any heavy usage with your test case:
>>>>>>
>>>>>> ~#free
>>>>>> total used free shared buffers
>>>>>> cached
>>>>>> Mem: 1028092 61364 966728 0 8416 22396
>>>>>> -/+ buffers/cache: 30552 997540
>>>>>> Swap: 0 0 0
>>>>>>
>>>>>>
>>>>>> Actually you didn't give any numbers. What kernel version are you using?
>>>>>>
>>>>> As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
>>>>> kernel (with PREEMPT-RT Patchset).
>>>>
>>>> Heh, funny coincidence. I was testing this on recent linux-leds.git,
>>>> for-next branch and was not able to detect the issue. It started to
>>>> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
>>>> that what fixes the issue is the most recent commit [1].
>>>>
>>>> Further investigation revealed that this is kobject_uevent_env(),
>>>> called from led_trigger_set(), which causes memory leaks when called
>>>> with high frequency.
>>>
>>> Really? Where in kobject_uevent_env() is the memory leak?
>>
>> I'll chase it down when and will let you know. This may be
>> non-trivial issue as it suffices to add "sleep 0.1" between
>> brightness setting operations to prevent it.
>
> Why are you abusing uevents for flashing an LED? Please don't do that,
> it's not what that interface is for at all.
It is called in a result of setting brightness value to LED_OFF,
which also removes registered trigger if any.
The rationale for calling kobject_uevent_env() is given in the
relevant commit message:
commit 52c47742f79d9240f90af9a6722fe8bb3fa8c0f9
Author: Colin Cross <ccross@android.com>
Date: Mon Aug 27 09:31:49 2012 +0800
leds: triggers: send uevent when changing triggers
Some triggers create sysfs files when they are enabled. Send a uevent
"change" notification whenever the trigger is changed to allow
userspace
processes such as udev to modify permissions on the new files.
A change notification will also be sent during registration of led
class
devices or led triggers if the default trigger of an led class device
is found.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 18:49 ` Jacek Anaszewski
@ 2016-09-16 19:44 ` Greg KH
2016-09-16 21:08 ` Jacek Anaszewski
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2016-09-16 19:44 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Jacek Anaszewski, Daniel Gorsulowski, linux-leds, linux-kernel
On Fri, Sep 16, 2016 at 08:49:44PM +0200, Jacek Anaszewski wrote:
> On 09/16/2016 04:39 PM, Greg KH wrote:
> > On Fri, Sep 16, 2016 at 04:32:39PM +0200, Jacek Anaszewski wrote:
> > > On 09/16/2016 04:06 PM, Greg KH wrote:
> > > > On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
> > > > > On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
> > > > > > Hi Jacek,
> > > > > >
> > > > > > Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
> > > > > > > On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
> > > > > > > > Hi Jacek,
> > > > > > > >
> > > > > > > > Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
> > > > > > > > > Hi Daniel,
> > > > > > > > >
> > > > > > > > > On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
> > > > > > > > > > Hello!
> > > > > > > > > >
> > > > > > > > > > Please consider if I made something wrong, sending this issue. This is
> > > > > > > > > > my first contact to the LKML.
> > > > > > > > > > By mistake, I accessed an LED via /sys/class/leds subsystem very
> > > > > > > > > > fast in
> > > > > > > > > > an user application. I figured out, that the free user memory
> > > > > > > > > > decreased
> > > > > > > > > > constantly. So I tried to analyze the Problem and wrote a litte
> > > > > > > > > > script:
> > > > > > > > > >
> > > > > > > > > > #!/bin/sh
> > > > > > > > > > while [ 1 ]; do
> > > > > > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > > > done
> > > > > > > > > >
> > > > > > > > > > And voila, I was able to reproduce the problem.
> > > > > > > > > > So I add a bit more debugging:
> > > > > > > > > >
> > > > > > > > > > #!/bin/sh
> > > > > > > > > > cnt=0
> > > > > > > > > > while [ 1 ]; do
> > > > > > > > > > if [ `expr $cnt % 1000` -eq 0 ]; then
> > > > > > > > > > free | grep Mem: | cut -d' ' -f25
> > > > > > > > > > fi
> > > > > > > > > > echo 1 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > > > echo 0 > /sys/class/leds/2a_service_yellow/brightness
> > > > > > > > > > let "cnt++"
> > > > > > > > > > done
> > > > > > > > > >
> > > > > > > > > > And huh? No memory is eaten anymore. So it looks like, the problem
> > > > > > > > > > only
> > > > > > > > > > occours on heavy (fast) usage of /sys/class/leds subsystem.
> > > > > > > > > >
> > > > > > > > > > I rewrote the script and toggled a GPIO pin, but there was no problem
> > > > > > > > > > recognizable.
> > > > > > > > >
> > > > > > > > > I've been unable to reproduce the problem with leds-aat1290 driver
> > > > > > > > > and Samsung M0 board. It must be driver specific issue.
> > > > > > > > > What driver did you use?
> > > > > > > > >
> > > > > > > > I defined LEDS_GPIO and so I'm using leds-gpio driver.
> > > > > > > > danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
> > > > > > > > -v "^# "
> > > > > > > > CONFIG_INPUT_LEDS=y
> > > > > > > > CONFIG_NEW_LEDS=y
> > > > > > > > CONFIG_LEDS_CLASS=y
> > > > > > > > CONFIG_LEDS_GPIO=y
> > > > > > > > CONFIG_LEDS_TRIGGERS=y
> > > > > > > > CONFIG_LEDS_TRIGGER_TIMER=y
> > > > > > > > CONFIG_LEDS_TRIGGER_ONESHOT=y
> > > > > > > > CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> > > > > > > > CONFIG_LEDS_TRIGGER_GPIO=y
> > > > > > > > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> > > > > > > > CONFIG_LEDS_TRIGGER_TRANSIENT=y
> > > > > > > >
> > > > > > >
> > > > > > > Unfortunately I am still unable to reproduce the problem with leds-gpio.
> > > > > > > I'm not observing any heavy usage with your test case:
> > > > > > >
> > > > > > > ~#free
> > > > > > > total used free shared buffers
> > > > > > > cached
> > > > > > > Mem: 1028092 61364 966728 0 8416 22396
> > > > > > > -/+ buffers/cache: 30552 997540
> > > > > > > Swap: 0 0 0
> > > > > > >
> > > > > > >
> > > > > > > Actually you didn't give any numbers. What kernel version are you using?
> > > > > > >
> > > > > > As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
> > > > > > kernel (with PREEMPT-RT Patchset).
> > > > >
> > > > > Heh, funny coincidence. I was testing this on recent linux-leds.git,
> > > > > for-next branch and was not able to detect the issue. It started to
> > > > > appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
> > > > > that what fixes the issue is the most recent commit [1].
> > > > >
> > > > > Further investigation revealed that this is kobject_uevent_env(),
> > > > > called from led_trigger_set(), which causes memory leaks when called
> > > > > with high frequency.
> > > >
> > > > Really? Where in kobject_uevent_env() is the memory leak?
> > >
> > > I'll chase it down when and will let you know. This may be
> > > non-trivial issue as it suffices to add "sleep 0.1" between
> > > brightness setting operations to prevent it.
> >
> > Why are you abusing uevents for flashing an LED? Please don't do that,
> > it's not what that interface is for at all.
>
> It is called in a result of setting brightness value to LED_OFF,
> which also removes registered trigger if any.
So every time the LED goes off a uevent happens? That's not a good
design.
> The rationale for calling kobject_uevent_env() is given in the
> relevant commit message:
>
> commit 52c47742f79d9240f90af9a6722fe8bb3fa8c0f9
> Author: Colin Cross <ccross@android.com>
> Date: Mon Aug 27 09:31:49 2012 +0800
>
> leds: triggers: send uevent when changing triggers
>
> Some triggers create sysfs files when they are enabled. Send a uevent
> "change" notification whenever the trigger is changed to allow userspace
> processes such as udev to modify permissions on the new files.
>
> A change notification will also be sent during registration of led class
> devices or led triggers if the default trigger of an led class device
> is found.
If a sysfs file is removed, then I could see a change event being ok.
But that's not what this patch does, it ALWAYS sends a uevent, even if
nothing changed!
Please fix that, otherwise you are going to really annoy userspace tools
with this.
But even then, I don't see how the uevent code has a memory leak with
this, do you? And why aren't you checking the return value of
kobject_uevent_env()?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 19:44 ` Greg KH
@ 2016-09-16 21:08 ` Jacek Anaszewski
2016-09-19 8:35 ` Jacek Anaszewski
0 siblings, 1 reply; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-16 21:08 UTC (permalink / raw)
To: Greg KH; +Cc: Jacek Anaszewski, Daniel Gorsulowski, linux-leds, linux-kernel
On 09/16/2016 09:44 PM, Greg KH wrote:
> On Fri, Sep 16, 2016 at 08:49:44PM +0200, Jacek Anaszewski wrote:
>> On 09/16/2016 04:39 PM, Greg KH wrote:
>>> On Fri, Sep 16, 2016 at 04:32:39PM +0200, Jacek Anaszewski wrote:
>>>> On 09/16/2016 04:06 PM, Greg KH wrote:
>>>>> On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
>>>>>> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
>>>>>>> Hi Jacek,
>>>>>>>
>>>>>>> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>>>>>>>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>>>>>>>> Hi Jacek,
>>>>>>>>>
>>>>>>>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>>>>>>>> Hi Daniel,
>>>>>>>>>>
>>>>>>>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>>>>>>>> Hello!
>>>>>>>>>>>
>>>>>>>>>>> Please consider if I made something wrong, sending this issue. This is
>>>>>>>>>>> my first contact to the LKML.
>>>>>>>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very
>>>>>>>>>>> fast in
>>>>>>>>>>> an user application. I figured out, that the free user memory
>>>>>>>>>>> decreased
>>>>>>>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>>>>>>>> script:
>>>>>>>>>>>
>>>>>>>>>>> #!/bin/sh
>>>>>>>>>>> while [ 1 ]; do
>>>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>> done
>>>>>>>>>>>
>>>>>>>>>>> And voila, I was able to reproduce the problem.
>>>>>>>>>>> So I add a bit more debugging:
>>>>>>>>>>>
>>>>>>>>>>> #!/bin/sh
>>>>>>>>>>> cnt=0
>>>>>>>>>>> while [ 1 ]; do
>>>>>>>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>>>>>>>> free | grep Mem: | cut -d' ' -f25
>>>>>>>>>>> fi
>>>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>> let "cnt++"
>>>>>>>>>>> done
>>>>>>>>>>>
>>>>>>>>>>> And huh? No memory is eaten anymore. So it looks like, the problem
>>>>>>>>>>> only
>>>>>>>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>>>>>>>
>>>>>>>>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>>>>>>>>> recognizable.
>>>>>>>>>>
>>>>>>>>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>>>>>>>>> and Samsung M0 board. It must be driver specific issue.
>>>>>>>>>> What driver did you use?
>>>>>>>>>>
>>>>>>>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>>>>>>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>>>>>>>>> -v "^# "
>>>>>>>>> CONFIG_INPUT_LEDS=y
>>>>>>>>> CONFIG_NEW_LEDS=y
>>>>>>>>> CONFIG_LEDS_CLASS=y
>>>>>>>>> CONFIG_LEDS_GPIO=y
>>>>>>>>> CONFIG_LEDS_TRIGGERS=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>>>>>>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately I am still unable to reproduce the problem with leds-gpio.
>>>>>>>> I'm not observing any heavy usage with your test case:
>>>>>>>>
>>>>>>>> ~#free
>>>>>>>> total used free shared buffers
>>>>>>>> cached
>>>>>>>> Mem: 1028092 61364 966728 0 8416 22396
>>>>>>>> -/+ buffers/cache: 30552 997540
>>>>>>>> Swap: 0 0 0
>>>>>>>>
>>>>>>>>
>>>>>>>> Actually you didn't give any numbers. What kernel version are you using?
>>>>>>>>
>>>>>>> As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
>>>>>>> kernel (with PREEMPT-RT Patchset).
>>>>>>
>>>>>> Heh, funny coincidence. I was testing this on recent linux-leds.git,
>>>>>> for-next branch and was not able to detect the issue. It started to
>>>>>> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
>>>>>> that what fixes the issue is the most recent commit [1].
>>>>>>
>>>>>> Further investigation revealed that this is kobject_uevent_env(),
>>>>>> called from led_trigger_set(), which causes memory leaks when called
>>>>>> with high frequency.
>>>>>
>>>>> Really? Where in kobject_uevent_env() is the memory leak?
>>>>
>>>> I'll chase it down when and will let you know. This may be
>>>> non-trivial issue as it suffices to add "sleep 0.1" between
>>>> brightness setting operations to prevent it.
>>>
>>> Why are you abusing uevents for flashing an LED? Please don't do that,
>>> it's not what that interface is for at all.
>>
>> It is called in a result of setting brightness value to LED_OFF,
>> which also removes registered trigger if any.
>
> So every time the LED goes off a uevent happens? That's not a good
> design.
We had a bug, but it was fixed with recent commit. Now the uevent
will happen when LED goes off only if trigger has been set.
>> The rationale for calling kobject_uevent_env() is given in the
>> relevant commit message:
>>
>> commit 52c47742f79d9240f90af9a6722fe8bb3fa8c0f9
>> Author: Colin Cross <ccross@android.com>
>> Date: Mon Aug 27 09:31:49 2012 +0800
>>
>> leds: triggers: send uevent when changing triggers
>>
>> Some triggers create sysfs files when they are enabled. Send a uevent
>> "change" notification whenever the trigger is changed to allow userspace
>> processes such as udev to modify permissions on the new files.
>>
>> A change notification will also be sent during registration of led class
>> devices or led triggers if the default trigger of an led class device
>> is found.
>
> If a sysfs file is removed, then I could see a change event being ok.
> But that's not what this patch does, it ALWAYS sends a uevent, even if
> nothing changed!
Yes, the function needs to be fixed. I'll submit relevant patch soon.
> Please fix that, otherwise you are going to really annoy userspace tools
> with this.
>
> But even then, I don't see how the uevent code has a memory leak with
> this, do you?
Not at the moment, but the fact is that the issue ceases to occur
after commenting the line out.
> And why aren't you checking the return value of
> kobject_uevent_env()?
Will fix.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 13:41 ` Jacek Anaszewski
2016-09-16 14:06 ` Greg KH
@ 2016-09-19 4:35 ` Daniel Gorsulowski
1 sibling, 0 replies; 15+ messages in thread
From: Daniel Gorsulowski @ 2016-09-19 4:35 UTC (permalink / raw)
To: Jacek Anaszewski, linux-leds; +Cc: linux-kernel, Greg KH
Hi Jacek,
Am 16.09.2016 um 15:41 schrieb Jacek Anaszewski:
> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
>> Hi Jacek,
>>
>> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>>> Hi Jacek,
>>>>
>>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>>> Hi Daniel,
>>>>>
>>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Please consider if I made something wrong, sending this issue. This is
>>>>>> my first contact to the LKML.
>>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem very
>>>>>> fast in
>>>>>> an user application. I figured out, that the free user memory
>>>>>> decreased
>>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>>> script:
>>>>>>
>>>>>> #!/bin/sh
>>>>>> while [ 1 ]; do
>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>> done
>>>>>>
>>>>>> And voila, I was able to reproduce the problem.
>>>>>> So I add a bit more debugging:
>>>>>>
>>>>>> #!/bin/sh
>>>>>> cnt=0
>>>>>> while [ 1 ]; do
>>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>>> free | grep Mem: | cut -d' ' -f25
>>>>>> fi
>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>> let "cnt++"
>>>>>> done
>>>>>>
>>>>>> And huh? No memory is eaten anymore. So it looks like, the problem
>>>>>> only
>>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>>
>>>>>> I rewrote the script and toggled a GPIO pin, but there was no problem
>>>>>> recognizable.
>>>>>
>>>>> I've been unable to reproduce the problem with leds-aat1290 driver
>>>>> and Samsung M0 board. It must be driver specific issue.
>>>>> What driver did you use?
>>>>>
>>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
>>>> -v "^# "
>>>> CONFIG_INPUT_LEDS=y
>>>> CONFIG_NEW_LEDS=y
>>>> CONFIG_LEDS_CLASS=y
>>>> CONFIG_LEDS_GPIO=y
>>>> CONFIG_LEDS_TRIGGERS=y
>>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>>
>>>
>>> Unfortunately I am still unable to reproduce the problem with leds-gpio.
>>> I'm not observing any heavy usage with your test case:
>>>
>>> ~#free
>>> total used free shared buffers
>>> cached
>>> Mem: 1028092 61364 966728 0 8416 22396
>>> -/+ buffers/cache: 30552 997540
>>> Swap: 0 0 0
>>>
>>>
>>> Actually you didn't give any numbers. What kernel version are you using?
>>>
>> As I wrote, the problems occurred in vanilla 4.6 kernel, but also in 4.4
>> kernel (with PREEMPT-RT Patchset).
>
> Heh, funny coincidence. I was testing this on recent linux-leds.git,
> for-next branch and was not able to detect the issue. It started to
> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
> that what fixes the issue is the most recent commit [1].
>
> Further investigation revealed that this is kobject_uevent_env(),
> called from led_trigger_set(), which causes memory leaks when called
> with high frequency.
>
> CC GregKH.
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-leds.git/commit/?h=for-next&id=f3f624941be0fafb29fff5c1411fa433feca792c
>
Nice to hear about the Fix, thanks for your investigation!
Kind regards,
Daniel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ISSUE] Memleak in LED sysfs on heavy usage
2016-09-16 21:08 ` Jacek Anaszewski
@ 2016-09-19 8:35 ` Jacek Anaszewski
0 siblings, 0 replies; 15+ messages in thread
From: Jacek Anaszewski @ 2016-09-19 8:35 UTC (permalink / raw)
To: Greg KH; +Cc: Jacek Anaszewski, Daniel Gorsulowski, linux-leds, linux-kernel
On 09/16/2016 11:08 PM, Jacek Anaszewski wrote:
>
> On 09/16/2016 09:44 PM, Greg KH wrote:
>> On Fri, Sep 16, 2016 at 08:49:44PM +0200, Jacek Anaszewski wrote:
>>> On 09/16/2016 04:39 PM, Greg KH wrote:
>>>> On Fri, Sep 16, 2016 at 04:32:39PM +0200, Jacek Anaszewski wrote:
>>>>> On 09/16/2016 04:06 PM, Greg KH wrote:
>>>>>> On Fri, Sep 16, 2016 at 03:41:09PM +0200, Jacek Anaszewski wrote:
>>>>>>> On 09/16/2016 02:08 PM, Daniel Gorsulowski wrote:
>>>>>>>> Hi Jacek,
>>>>>>>>
>>>>>>>> Am 16.09.2016 um 13:25 schrieb Jacek Anaszewski:
>>>>>>>>> On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
>>>>>>>>>> Hi Jacek,
>>>>>>>>>>
>>>>>>>>>> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>>>>>>>>>>> Hi Daniel,
>>>>>>>>>>>
>>>>>>>>>>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>>>>>>>>>>> Hello!
>>>>>>>>>>>>
>>>>>>>>>>>> Please consider if I made something wrong, sending this
>>>>>>>>>>>> issue. This is
>>>>>>>>>>>> my first contact to the LKML.
>>>>>>>>>>>> By mistake, I accessed an LED via /sys/class/leds subsystem
>>>>>>>>>>>> very
>>>>>>>>>>>> fast in
>>>>>>>>>>>> an user application. I figured out, that the free user memory
>>>>>>>>>>>> decreased
>>>>>>>>>>>> constantly. So I tried to analyze the Problem and wrote a litte
>>>>>>>>>>>> script:
>>>>>>>>>>>>
>>>>>>>>>>>> #!/bin/sh
>>>>>>>>>>>> while [ 1 ]; do
>>>>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>>> done
>>>>>>>>>>>>
>>>>>>>>>>>> And voila, I was able to reproduce the problem.
>>>>>>>>>>>> So I add a bit more debugging:
>>>>>>>>>>>>
>>>>>>>>>>>> #!/bin/sh
>>>>>>>>>>>> cnt=0
>>>>>>>>>>>> while [ 1 ]; do
>>>>>>>>>>>> if [ `expr $cnt % 1000` -eq 0 ]; then
>>>>>>>>>>>> free | grep Mem: | cut -d' ' -f25
>>>>>>>>>>>> fi
>>>>>>>>>>>> echo 1 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>>> echo 0 > /sys/class/leds/2a_service_yellow/brightness
>>>>>>>>>>>> let "cnt++"
>>>>>>>>>>>> done
>>>>>>>>>>>>
>>>>>>>>>>>> And huh? No memory is eaten anymore. So it looks like, the
>>>>>>>>>>>> problem
>>>>>>>>>>>> only
>>>>>>>>>>>> occours on heavy (fast) usage of /sys/class/leds subsystem.
>>>>>>>>>>>>
>>>>>>>>>>>> I rewrote the script and toggled a GPIO pin, but there was
>>>>>>>>>>>> no problem
>>>>>>>>>>>> recognizable.
>>>>>>>>>>>
>>>>>>>>>>> I've been unable to reproduce the problem with leds-aat1290
>>>>>>>>>>> driver
>>>>>>>>>>> and Samsung M0 board. It must be driver specific issue.
>>>>>>>>>>> What driver did you use?
>>>>>>>>>>>
>>>>>>>>>> I defined LEDS_GPIO and so I'm using leds-gpio driver.
>>>>>>>>>> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep
>>>>>>>>>> LEDS | grep
>>>>>>>>>> -v "^# "
>>>>>>>>>> CONFIG_INPUT_LEDS=y
>>>>>>>>>> CONFIG_NEW_LEDS=y
>>>>>>>>>> CONFIG_LEDS_CLASS=y
>>>>>>>>>> CONFIG_LEDS_GPIO=y
>>>>>>>>>> CONFIG_LEDS_TRIGGERS=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_TIMER=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_ONESHOT=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_GPIO=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>>>>>>>>>> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unfortunately I am still unable to reproduce the problem with
>>>>>>>>> leds-gpio.
>>>>>>>>> I'm not observing any heavy usage with your test case:
>>>>>>>>>
>>>>>>>>> ~#free
>>>>>>>>> total used free shared buffers
>>>>>>>>> cached
>>>>>>>>> Mem: 1028092 61364 966728 0
>>>>>>>>> 8416 22396
>>>>>>>>> -/+ buffers/cache: 30552 997540
>>>>>>>>> Swap: 0 0 0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually you didn't give any numbers. What kernel version are
>>>>>>>>> you using?
>>>>>>>>>
>>>>>>>> As I wrote, the problems occurred in vanilla 4.6 kernel, but
>>>>>>>> also in 4.4
>>>>>>>> kernel (with PREEMPT-RT Patchset).
>>>>>>>
>>>>>>> Heh, funny coincidence. I was testing this on recent linux-leds.git,
>>>>>>> for-next branch and was not able to detect the issue. It started to
>>>>>>> appear after resetting HEAD to 4.8-rc2 base. Finally it turned out
>>>>>>> that what fixes the issue is the most recent commit [1].
>>>>>>>
>>>>>>> Further investigation revealed that this is kobject_uevent_env(),
>>>>>>> called from led_trigger_set(), which causes memory leaks when called
>>>>>>> with high frequency.
>>>>>>
>>>>>> Really? Where in kobject_uevent_env() is the memory leak?
>>>>>
>>>>> I'll chase it down when and will let you know. This may be
>>>>> non-trivial issue as it suffices to add "sleep 0.1" between
>>>>> brightness setting operations to prevent it.
>>>>
>>>> Why are you abusing uevents for flashing an LED? Please don't do that,
>>>> it's not what that interface is for at all.
>>>
>>> It is called in a result of setting brightness value to LED_OFF,
>>> which also removes registered trigger if any.
>>
>> So every time the LED goes off a uevent happens? That's not a good
>> design.
>
> We had a bug, but it was fixed with recent commit. Now the uevent
> will happen when LED goes off only if trigger has been set.
>
>>> The rationale for calling kobject_uevent_env() is given in the
>>> relevant commit message:
>>>
>>> commit 52c47742f79d9240f90af9a6722fe8bb3fa8c0f9
>>> Author: Colin Cross <ccross@android.com>
>>> Date: Mon Aug 27 09:31:49 2012 +0800
>>>
>>> leds: triggers: send uevent when changing triggers
>>>
>>> Some triggers create sysfs files when they are enabled. Send a
>>> uevent
>>> "change" notification whenever the trigger is changed to allow
>>> userspace
>>> processes such as udev to modify permissions on the new files.
>>>
>>> A change notification will also be sent during registration of
>>> led class
>>> devices or led triggers if the default trigger of an led class
>>> device
>>> is found.
>>
>> If a sysfs file is removed, then I could see a change event being ok.
>> But that's not what this patch does, it ALWAYS sends a uevent, even if
>> nothing changed!
>
> Yes, the function needs to be fixed. I'll submit relevant patch soon.
>
>> Please fix that, otherwise you are going to really annoy userspace tools
>> with this.
>>
>> But even then, I don't see how the uevent code has a memory leak with
>> this, do you?
On x86_64 memory usage grows by ~50kB, and than gets back to the value
from before launching the stress test. It doesn't start to grow again.
On exynos4412-trats2 board memory usage grows by 240Mb and then it
gradually drops, so this is certainly not a memory leak, but some
other platform specific memory management related issue.
It will perform further investigation, in a spare time.
> Not at the moment, but the fact is that the issue ceases to occur
> after commenting the line out.
>
>> And why aren't you checking the return value of
>> kobject_uevent_env()?
>
> Will fix.
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-09-19 8:35 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20160912085832eucas1p1e7332f761e5e0cb764a6831b9a519b70@eucas1p1.samsung.com>
2016-09-12 8:50 ` [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski
2016-09-13 7:16 ` Jacek Anaszewski
2016-09-16 7:31 ` Jacek Anaszewski
2016-09-16 8:15 ` Daniel Gorsulowski
2016-09-16 11:25 ` Jacek Anaszewski
2016-09-16 12:08 ` Daniel Gorsulowski
2016-09-16 13:41 ` Jacek Anaszewski
2016-09-16 14:06 ` Greg KH
2016-09-16 14:32 ` Jacek Anaszewski
2016-09-16 14:39 ` Greg KH
2016-09-16 18:49 ` Jacek Anaszewski
2016-09-16 19:44 ` Greg KH
2016-09-16 21:08 ` Jacek Anaszewski
2016-09-19 8:35 ` Jacek Anaszewski
2016-09-19 4:35 ` Daniel Gorsulowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.