* [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 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
* 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
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.