Re: [ISSUE] Memleak in LED sysfs on heavy usage

From: Jacek Anaszewski
Date: Fri Sep 16 2016 - 14:51:07 EST

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:

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
constantly. So I tried to analyze the Problem and wrote a litte

while [ 1 ]; do
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness

And voila, I was able to reproduce the problem.
So I add a bit more debugging:

while [ 1 ]; do
if [ `expr $cnt % 1000` -eq 0 ]; then
free | grep Mem: | cut -d' ' -f25
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness
let "cnt++"

And huh? No memory is eaten anymore. So it looks like, the problem
occours on heavy (fast) usage of /sys/class/leds subsystem.

I rewrote the script and toggled a GPIO pin, but there was no problem

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 "^# "

Unfortunately I am still unable to reproduce the problem with leds-gpio.
I'm not observing any heavy usage with your test case:

total used free shared buffers
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@xxxxxxxxxxx>
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