From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754331AbcIMHRH (ORCPT ); Tue, 13 Sep 2016 03:17:07 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:28093 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751547AbcIMHRE (ORCPT ); Tue, 13 Sep 2016 03:17:04 -0400 X-AuditID: cbfec7f5-f79ce6d000004c54-72-57d7a7ecd3f6 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: <0af86c53-7583-8cff-1fbd-ef12f28d15f9@samsung.com> Date: Tue, 13 Sep 2016 09:16:58 +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+NgFnrFIsWRmVeSWpSXmKPExsWy7djPc7pvll8PN7gwQ8FiS3Mzo8XlXXPY LLa+WcfowOzx58ILZo/Pm+QCmKK4bFJSczLLUov07RK4MrY0sRbcF6l4cOkPewPjG94uRk4O CQETiYUTJjBC2GISF+6tZwOxhQSWMkrcW+cOYX9mlFh43wCm/vCMH0D1XEDxZYwSexsuskMU PWOUeHipCsQWFrCQWL3sLNhQEYF8iZtn3zCB2MwCjhKPLt9hBrHZBAwlfr54DRbnFbCTaFo+ FWwxi4CqxOn2TUAzOThEBSIkdt9NhSgRlPgx+R4LSJhTwEriXzcHxEQriWf/WlkhbHmJzWve MoOcJiHwmU3i36ePzCD1EgKyEpsOMEOc7yLReHsdO4QtLPHq+BYoW0ais+MgE0TvZEaJi8du skI4qxklNnZ2skBUWUs0/P/FArGNT2LStulQC3glOtqEIEo8JHau2wW1zFFi5uLD0LDqZZTo /7adfQKj/Cwk/8xC8sQsJE8sYGRexSiSWlqcm55abKpXnJhbXJqXrpecn7uJEZgCTv87/nUH 49JjVocYBTgYlXh4G1ZfCxdiTSwrrsw9xCjBwawkwvt+yfVwId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rx7FlwJFxJITyxJzU5NLUgtgskycXBKNTDmmvnv7qxK1c5cdP1Fk/WfpA9fnrs5xZ2z nKhj3Bh4RrHnufgbpwKD+YolZUYxbJdnHhM/GKuV/ljojd7GJw5Xq+ZIpPore7bu+/xkbdcL TtkOp9CSKSfEVJnK249VL1Cb/nP/kmCPA6HNpi4M92/dOfhU+diEred/2nkzvogz5BScs6lZ sF2JpTgj0VCLuag4EQAZFzxh/QIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42I5/e/4Fd29y6+HG3TPF7fY0tzMaHF51xw2 i61v1jE6MHv8ufCC2ePzJrkApig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd 35AgJYWyxJxSIM/IAA04OAe4Byvp2yW4ZWxpYi24L1Lx4NIf9gbGN7xdjJwcEgImEodn/GCE sMUkLtxbz9bFyMUhJLCEUWLfxUWsEM4zRonNX1+xgFQJC1hIrF52FqxDRCBfYu7PRmYQW0ig n1HixB0xEJtZwFHi0eU7YHE2AUOJny9eM4HYvAJ2Ek3Lp7KB2CwCqhKn2zexg9iiAhESt1Z9 ZISoEZT4Mfke0C4ODk4BK4l/3RwQI80kvrw8zAphy0tsXvOWeQKjwCwkHbOQlM1CUraAkXkV o0hqaXFuem6xoV5xYm5xaV66XnJ+7iZGYExsO/Zz8w7GSxuDDzEKcDAq8fA2rL4WLsSaWFZc mXuIUYKDWUmE9/2S6+FCvCmJlVWpRfnxRaU5qcWHGE2BfpjILCWanA+M17ySeEMTQ3NLQyNj CwtzIyMlcd6SD1fChQTSE0tSs1NTC1KLYPqYODilGhhn2C/oXaT46VSS+VSuPTzba3vrFkRs 1J5o/kHWIK9YvfLYD5b++dfcz35o+2Ubl2Qya9ddaa2jb4oO/51/jLmYY9vh+eIrEoOi2Jvt 9qbwT/5XYPkhwcc0hGsbg+HZz/b5ja9DtKK/Z50o5ljecXz+jddeD27nX95XfvM3S/eHmxP2 fbS9GHBaiaU4I9FQi7moOBEAA95cL58CAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160913071659eucas1p2736e2360579d2672fe26913b00bbca7b X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 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: 20160912085832eucas1p1e7332f761e5e0cb764a6831b9a519b70 X-RootMTR: 20160912085832eucas1p1e7332f761e5e0cb764a6831b9a519b70 References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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