Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2236002ybh; Mon, 9 Mar 2020 01:42:33 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtZhfs+6S+v54myZ93O/AF+d4pXFoom6ZB3t7dT1gQRleVN7eJOqDYlwnUNsEwNg59d3Rz4 X-Received: by 2002:a9d:7d0c:: with SMTP id v12mr12198555otn.171.1583743353660; Mon, 09 Mar 2020 01:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583743353; cv=none; d=google.com; s=arc-20160816; b=WqF1BcE+VBIvOxGykWotPhwlPt3SATR9MvPKVL92DQIJx7wV3dNqkVIGjdRfl2dU+5 pRGscacC4i2nE7xsVpDjz+PcD8dNhezcpGZZTddY4zjLqJSNUcvCNOM2nU16jJVp4aNw HGTcJ4HF8tepAFqJ35FgHEYMbfs8vVockuCrHVBYPlzoWYmYLiP45UwfKXEXT0OsQ0hx zF1kZY7NSf+LqLbiOKfueR46yDhKqp2lvFWQ8GLfQrbZaz1GOdkrGCySYavdGmUH8Ij1 gawM7Q9wLHfjZpu+gULdbfYOeB81jPMCwgUxlNTcADAMT0lQ8koDi5KGeJLjmg9QNhbb PvYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Nh32E72UoBY8+QkjYIAcs0RUl9/fFF38Qu7Vp++5nOk=; b=cggap2OWXVbbWv2MgoqZl0wgLRP9HA77UvH1q0jwxQbELLn5BwD98bFh+g+kGelug6 CggnRO76tEb/FDNbDgw/Ssr5OSiz5d7ejQ7inH2kRbMROnUcZBay6IiHDjyJLz3SLlCb rz3B1Dy9o1uYecd761FAKmgRLo8wG01s8GtFYtz4pQRShi/firWB6k/EvUekea+eVldW 8g3kLKG3cBcIav4Ri+fAw3Cj3Xknz/vkf/NqdR4AqJmyhtRXazOsBIl+fM48p8BLJtTx c5ZoO/6D18+n6yNIDXp9G7+C5/7Hi2By/RPlE0Ev4eY4udwHI5ifrtfRsXC7s04VHWcn wpVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si5534561ota.103.2020.03.09.01.42.22; Mon, 09 Mar 2020 01:42:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726558AbgCIIlG (ORCPT + 99 others); Mon, 9 Mar 2020 04:41:06 -0400 Received: from foss.arm.com ([217.140.110.172]:49128 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726450AbgCIIlG (ORCPT ); Mon, 9 Mar 2020 04:41:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9BEA11FB; Mon, 9 Mar 2020 01:41:05 -0700 (PDT) Received: from [10.37.12.74] (unknown [10.37.12.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 454DD3F6CF; Mon, 9 Mar 2020 01:41:02 -0700 (PDT) Subject: Re: [PATCH] drm/exynos: Fix memory leak and release IOMMU mapping structures To: Inki Dae , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Cc: jy0922.shim@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, airlied@linux.ie, daniel@ffwll.ch, kgene@kernel.org, krzk@kernel.org, b.zolnierkie@samsung.com, a.hajda@samsung.com, Dietmar.Eggemann@arm.com References: <20200304220022.8003-1-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: <7962c9f2-e85d-9f9b-f442-c4a5b387ca44@arm.com> Date: Mon, 9 Mar 2020 08:41:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Inki, On 3/9/20 12:45 AM, Inki Dae wrote: > Hi Lukasz, > > 20. 3. 5. 오전 7:00에 Lukasz Luba 이(가) 쓴 글: >> There is a memory leak which left some objects not freed. The reference >> counter of mapping: 'mapping->kref' was 2 when calling >> arm_iommu_detach_device(), so the release_iommu_mapping() won't be called. >> Since the old mapping structure is not going to be used any more (because >> it is detached and new one attached), call arm_iommu_release_mapping() >> to trigger cleanup. >> >> Found using kmemleak detector, the output: >> [snip] >> >> Signed-off-by: Lukasz Luba >> --- >> >> Hi all, >> >> I have discovered this issue on OdroidXU4 while running some stress tests >> for upcoming Energy Model. To reproduce it, kernel must be compiled with >> DEBUG_KMEMLEAK. When the boot has finished, type: >> # echo scan > /sys/kernel/debug/kmemleak >> # cat /sys/kernel/debug/kmemleak >> You should expect similar output to the one from the commit message. >> >> I don't know if it should go via stable tree as well. I can resend with CC >> stable, if there is a need. > > Thanks for fixup. BTW, as you commented on Marek's patch thread, with Marek's patch the memory leak will be solved. > Do you want Marek to rework his patch on top of your patch or are you ok me to pick up only Marek's one? Please drop this one and apply only Marek's patch, it fixes the issue. I didn't know that he was working on similar stuff. > > Marek's patch is conflicted with your one. > > Thanks, > Inki Dae Regards, Lukasz