Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1481053 > unrolled thread

[ISSUE] Memleak in LED sysfs on heavy usage

Started byDaniel Gorsulowski <daniel.gorsulowski@esd.eu>
First post2016-09-12 11:00 +0200
Last post2016-09-19 06:40 +0200
Articles 15 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski <daniel.gorsulowski@esd.eu> - 2016-09-12 11:00 +0200
    Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-13 09:20 +0200
    Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-16 09:40 +0200
      Re: [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski <daniel.gorsulowski@esd.eu> - 2016-09-16 10:20 +0200
        Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-16 13:30 +0200
          Re: [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski <daniel.gorsulowski@esd.eu> - 2016-09-16 14:10 +0200
            Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-16 15:50 +0200
              Re: [ISSUE] Memleak in LED sysfs on heavy usage Greg KH <greg@kroah.com> - 2016-09-16 16:10 +0200
                Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-16 16:40 +0200
                  Re: [ISSUE] Memleak in LED sysfs on heavy usage Greg KH <greg@kroah.com> - 2016-09-16 16:50 +0200
                    Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-09-16 21:00 +0200
                      Re: [ISSUE] Memleak in LED sysfs on heavy usage Greg KH <greg@kroah.com> - 2016-09-16 21:50 +0200
                        Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-09-16 23:10 +0200
                          Re: [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-09-19 10:40 +0200
              Re: [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski <daniel.gorsulowski@esd.eu> - 2016-09-19 06:40 +0200

#1481053 — [ISSUE] Memleak in LED sysfs on heavy usage

FromDaniel Gorsulowski <daniel.gorsulowski@esd.eu>
Date2016-09-12 11:00 +0200
Subject[ISSUE] Memleak in LED sysfs on heavy usage
Message-ID<sgvfQ-VS-25@gated-at.bofh.it>
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

[toc] | [next] | [standalone]

#1482191

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-13 09:20 +0200
Message-ID<sgQaC-72V-9@gated-at.bofh.it>
In reply to#1481053
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

[toc] | [prev] | [next] | [standalone]

#1484739

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-16 09:40 +0200
Message-ID<shVUB-1AV-5@gated-at.bofh.it>
In reply to#1481053
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

[toc] | [prev] | [next] | [standalone]

#1484771

FromDaniel Gorsulowski <daniel.gorsulowski@esd.eu>
Date2016-09-16 10:20 +0200
Message-ID<shWxj-28o-13@gated-at.bofh.it>
In reply to#1484739
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
>>
>>
>>
>
>

[toc] | [prev] | [next] | [standalone]

#1484899

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-16 13:30 +0200
Message-ID<shZvg-40T-5@gated-at.bofh.it>
In reply to#1484771
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

[toc] | [prev] | [next] | [standalone]

#1484926

FromDaniel Gorsulowski <daniel.gorsulowski@esd.eu>
Date2016-09-16 14:10 +0200
Message-ID<si07U-4uJ-9@gated-at.bofh.it>
In reply to#1484899
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

[toc] | [prev] | [next] | [standalone]

#1485001

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-16 15:50 +0200
Message-ID<si1GF-5m2-3@gated-at.bofh.it>
In reply to#1484926
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

[toc] | [prev] | [next] | [standalone]

#1485009

FromGreg KH <greg@kroah.com>
Date2016-09-16 16:10 +0200
Message-ID<si201-5IX-1@gated-at.bofh.it>
In reply to#1485001
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

[toc] | [prev] | [next] | [standalone]

#1485059

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-16 16:40 +0200
Message-ID<si2t3-5We-21@gated-at.bofh.it>
In reply to#1485009
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

[toc] | [prev] | [next] | [standalone]

#1485068

FromGreg KH <greg@kroah.com>
Date2016-09-16 16:50 +0200
Message-ID<si2CK-608-21@gated-at.bofh.it>
In reply to#1485059
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

[toc] | [prev] | [next] | [standalone]

#1485244

FromJacek Anaszewski <jacek.anaszewski@gmail.com>
Date2016-09-16 21:00 +0200
Message-ID<si6wF-8E-1@gated-at.bofh.it>
In reply to#1485068
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

[toc] | [prev] | [next] | [standalone]

#1485280

FromGreg KH <greg@kroah.com>
Date2016-09-16 21:50 +0200
Message-ID<si7j3-FB-11@gated-at.bofh.it>
In reply to#1485244
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

[toc] | [prev] | [next] | [standalone]

#1485376

FromJacek Anaszewski <jacek.anaszewski@gmail.com>
Date2016-09-16 23:10 +0200
Message-ID<si8yu-1HA-25@gated-at.bofh.it>
In reply to#1485280
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

[toc] | [prev] | [next] | [standalone]

#1486258

FromJacek Anaszewski <j.anaszewski@samsung.com>
Date2016-09-19 10:40 +0200
Message-ID<sj2hk-35A-13@gated-at.bofh.it>
In reply to#1485376
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

[toc] | [prev] | [next] | [standalone]

#1486130

FromDaniel Gorsulowski <daniel.gorsulowski@esd.eu>
Date2016-09-19 06:40 +0200
Message-ID<siYx3-N5-1@gated-at.bofh.it>
In reply to#1485001
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web