From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756885AbcIPHcM (ORCPT ); Fri, 16 Sep 2016 03:32:12 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:34738 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388AbcIPHcE (ORCPT ); Fri, 16 Sep 2016 03:32:04 -0400 X-AuditID: cbfec7f1-f79f46d0000008eb-5c-57db9ff0705d 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: <37b949b3-6a9a-b8e3-c164-5ac2d44c9b3c@samsung.com> Date: Fri, 16 Sep 2016 09:31: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+NgFnrLIsWRmVeSWpSXmKPExsWy7djP87of5t8ON9j5VNRiS3Mzo8XlXXPY LLa+WcfowOzx58ILZo/Pm+QCmKK4bFJSczLLUov07RK4MrquPGAqOCBesfJOJ2sDY4dAFyMn h4SAicSDXcdYIGwxiQv31rN1MXJxCAksZZT4/fYaI0hCSOAzo8SVZ+IwDSeW7GKBKFrGKHF7 7i5WCOcZo8Sd36uZQaqEBSwkVi87C9YtIpAvcfPsGyYQm1nAUeLR5TtgNWwChhI/X7wGi/MK 2EkcnbmMFcRmEVCVON7wFqiGg0NUIEJi991UiBJBiR+T77GAhDkFrCT+dXNATLSSePavlRXC lpfYvAakkwvozs9sEqvXPmYDqZcQkJXYdIAZ4n4XiWvvFzJC2MISr45vYYewZSQ6Ow4yQfRO ZpS4eOwmK4SzmlFiY2cnNIisJRr+/2KB2MYnMWnbdGaIBbwSHW1CECUeEjvX7YJa5igxc/Fh Rkj49DJK9H/bzj6BUX4Wkn9mIXliFpInFjAyr2IUSS0tzk1PLTbSK07MLS7NS9dLzs/dxAhM BKf/Hf+4g/H9CatDjAIcjEo8vCvm3goXYk0sK67MPcQowcGsJMK7dN7tcCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8exZcCRcSSE8sSc1OTS1ILYLJMnFwSjUwWi1cXxj2+eWmjKqIB4xp3EmT 7+92NM4wd3FKmlnodlok+F+Bm+zCeztk3CVUV691v5EwI+OHytXKk77BFdfe1SW/aQmx2/kq 7MLCu8u6r/dcXvyu7FDdmxc+K9sY2P5XZ/9cYRx5qfYf4+ayC2rcobeVn9zZduDzqi3tJWUz +yrYIq44X/mgq8RSnJFoqMVcVJwIAIMo75cAAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42I5/e/4Zd0j82+HGzQc4rfY0tzMaHF51xw2 i61v1jE6MHv8ufCC2ePzJrkApig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd 35AgJYWyxJxSIM/IAA04OAe4Byvp2yW4ZXRdecBUcEC8YuWdTtYGxg6BLkZODgkBE4kTS3ax QNhiEhfurWfrYuTiEBJYwijx7uUsFgjnGaPE01kPwaqEBSwkVi87ywhiiwjkS8z92cgMYgsJ 9DNKnLgjBmIzCzhKPLp8ByzOJmAo8fPFayYQm1fATuLozGWsIDaLgKrE8Ya3YDWiAhESt1Z9 ZISoEZT4Mfke0C4ODk4BK4l/3RwQI80kvrw8zAphy0tsXvOWeQKjwCwkHbOQlM1CUraAkXkV o0hqaXFuem6xoV5xYm5xaV66XnJ+7iZGYFRsO/Zz8w7GSxuDDzEKcDAq8fAGzL4VLsSaWFZc mXuIUYKDWUmEd+m82+FCvCmJlVWpRfnxRaU5qcWHGE2BfpjILCWanA+M2LySeEMTQ3NLQyNj CwtzIyMlcd6SD1fChQTSE0tSs1NTC1KLYPqYODilGhjrZkWn+UqUOHUdsxE9NNkpqPnz2oOu x08lzO4wP1mwaT4jv9GRK26Pp3O+eJS2hedIS16yYANX6eUH/lUrPk4Id9rp6zFZwzz2wtT5 nIXLHPyE/7zftClkq8+CDDFVXVfG6e5+53wfq80QqZd+atdyhcP1wyEDrnNG7jVdS8R1JH/P l94m/FWJpTgj0VCLuag4EQCTcJU7oAIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160916073159eucas1p2ca3bcca46e1ecd5f0dea08b7a6a2b327 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. 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