From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752785AbcIPLZX (ORCPT ); Fri, 16 Sep 2016 07:25:23 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:46972 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933839AbcIPLZN (ORCPT ); Fri, 16 Sep 2016 07:25:13 -0400 X-AuditID: cbfec7f5-f79ce6d000004c54-5b-57dbd6956500 Subject: Re: [ISSUE] Memleak in LED sysfs on heavy usage To: Daniel Gorsulowski , "linux-leds@vger.kernel.org" Cc: "linux-kernel@vger.kernel.org" From: Jacek Anaszewski Message-id: <4d51014d-c8fa-4687-cae8-1a8dd0f79beb@samsung.com> Date: Fri, 16 Sep 2016 13:25:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsWy7djPc7pTr90ON3jzWdxiS3Mzo8XlXXPY LLa+WcfowOzx58ILZo/Pm+QCmKK4bFJSczLLUov07RK4Mq6uOM9Y8Em4Yvu/5ewNjA38XYyc HBICJhL3nv5nhbDFJC7cW8/WxcjFISSwlFGi+egUKOczo8TfPpgqE4lVzzcyQSSWMUrc29AO VfWMUWLCiQdsIFXCAhYSq5edZQSxRQTyJW6efcMEYjMLOEo8unyHGcRmEzCU+PniNVicV8BO 4sqbh0A2BweLgKrEw84EEFNUIEJi991UiApBiR+T77GA2JwCVhK/3hyEmmgl8exfKyuELS+x ec1bZpBzJAQ+s0k8v3KXEWSOhICsxKYDzBD3u0isePqOCcIWlnh1fAs7hC0jcXlyNwtE72RG iYvHbrJCOKsZJTZ2drJAVFlLNPz/xQKxjU9i0rbpzBALeCU62oQgSjwk7k+dCVXuKLF+zRNG SPgcYpQ42fOQeQKj/CwkD81C8sQsJE8sYGRexSiSWlqcm55abKpXnJhbXJqXrpecn7uJEZgK Tv87/nUH49JjVocYBTgYlXh4V8y9FS7EmlhWXJkLtIiDWUmEd9Hl2+FCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEefcsuBIuJJCeWJKanZpakFoEk2Xi4JRqYLRees3+vu5J5ext206qvdC7+u3K 4Z/rTqewPxV32ph8tlJ3QThv+7cA47ueaRGiWmeuP1Y3ea/G4X3pH3vP5pLDu6Q2VJW5rC9k ypr3zv+Fw5doYbkO9+DqKOXsuVOCIowdmPlfPZrJv3JzcabGaZeSqXvCbbdN2nzI9+JcUbuQ x7k/Ds699FaJpTgj0VCLuag4EQCyGr2rAQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42I5/e/4Zd3Ua7fDDeYfVbLY0tzMaHF51xw2 i61v1jE6MHv8ufCC2ePzJrkApig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd 35AgJYWyxJxSIM/IAA04OAe4Byvp2yW4ZVxdcZ6x4JNwxfZ/y9kbGBv4uxg5OSQETCRWPd/I BGGLSVy4t54NxBYSWMIosX9/VRcjF5D9jFFi661DLCAJYQELidXLzjKC2CIC+RJzfzYyQxQd YpSYdewWWIJZwFHi0eU7zCA2m4ChxM8Xr8E28ArYSVx58xDI5uBgEVCVeNiZABIWFYiQuLXq IyNEiaDEj8n3wHZxClhJ/HpzkAlipJnEl5eHWSFseYnNa94yT2AUmIWkZRaSsllIyhYwMq9i FEktLc5Nzy020itOzC0uzUvXS87P3cQIjIptx35u2cHY9S74EKMAB6MSD++KubfChVgTy4or c4F+4mBWEuFddPl2uBBvSmJlVWpRfnxRaU5q8SFGU6AfJjJLiSbnAyM2ryTe0MTQ3NLQyNjC wtzISEmcd+qHK+FCAumJJanZqakFqUUwfUwcnFINjBYF6iaOGc+qC7gmxX3JWvkq/HfiDJsD M7L73Z7qtttNTjr2/8Afh973q7yUWrcHXHPbvrbErWHiJ8bZssUnhdm/CAju/f5he/6k7T9a 3xic2C5wemvDQQYdy6xzzU+P30qU/bLiwdmp1utYZE7OvN+QM8PsIO/hvxwLrlvn2zre2yK+ /k2OzyUlluKMREMt5qLiRAB5idr8oAIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160916112509eucas1p29d25fde258d4bfa98d0df17f2921b01a X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?SmFjZWsgQW5hc3pld3NraRtTUlBPTC1TeXN0ZW0gRlcgIChN?= =?UTF-8?B?Qikb7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?SmFjZWsgQW5hc3pld3NraRtTUlBPTC1TeXN0ZW0gRlcgIChN?= =?UTF-8?B?QikbU2Ftc3VuZyBFbGVjdHJvbmljcxtTZW5pb3IgU29mdHdhcmUgRW5naW5l?= =?UTF-8?B?ZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjc1MjY=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20160916081559eucas1p14d332c2eecb07992746c96b7163f5172 X-RootMTR: 20160916081559eucas1p14d332c2eecb07992746c96b7163f5172 References: <37b949b3-6a9a-b8e3-c164-5ac2d44c9b3c@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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