Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp866343ybz; Wed, 29 Apr 2020 10:45:09 -0700 (PDT) X-Google-Smtp-Source: APiQypLEKLrQTU+lai+yMyuaZLCWy8ptqmAEoVsS2eyh33v+aboRiuA1Kn/P7hKdpyEfd9wKvShU X-Received: by 2002:a05:6402:3129:: with SMTP id dd9mr3598564edb.121.1588182309367; Wed, 29 Apr 2020 10:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588182309; cv=none; d=google.com; s=arc-20160816; b=mi8Wsnz1vz/qD3uAIC0wQ9oj6pr4MrE3LnqZl6k7sLN0UCfBxFXFiLPDlwqhSTSxPO HHnBi8dvFtEoIPWxB5JMfesLP/nQccWkVj7R9zu9G7wkC3scpHKmMxC+k1YXkuwCJ1c6 dOWgQhcP3a6+Q+riGjWxRjvM4fn/UkRyp0aQ/DEjY0kmbgM0a4k209GvRYTRnPX9eqFI vfv798ahZ9IoN5Ef9LpH8culATVzJw1u38mVLBxI7BDlnb2VdRhHcV1ZsZTz5l86wqzl ZaL/2bVt+h8C35GYAVvophxp4RP0jqQPacNtCCuDiGoUkBL0eztMZLM7UaXf0nx8FdbO bDBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=eR3qyIeNXprMaAk4qQW4kavys8iZavWhYnQSkCNuPcQ=; b=p7M3BCZf0fKeVuObIjLpHWWEXMgdhIvlRylwKXlCYF/iPJjfvm207mzY1cmYN7YWz4 C5YKujoVAIrDTdPqlsmgHblNWcMt2kcVZYpL1qyU9djhjNYN7J92Kpv342f7Tw22+cgY KylSGBqrZ41A39+Bj8LAiTSghuZ+Fh7p+MruzO2ecGQeTi6rDSRZo/vLQltMnkZDCuy7 N80kEFgth3igy0HKt1JLKXFh0aZw9r1lmlZL+gy0cpnmufAEiQjDodSvCFzOZviTJsDh HzhQY+PqzDqaNKPvtm0bg8W1eysyzR8StS9ris7Q7sWN6I7hWBdHWEMmznJrsaaT+pOx MDlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc26si1789876edb.169.2020.04.29.10.44.45; Wed, 29 Apr 2020 10:45:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726781AbgD2Rmu (ORCPT + 99 others); Wed, 29 Apr 2020 13:42:50 -0400 Received: from smtp03.smtpout.orange.fr ([80.12.242.125]:40896 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726524AbgD2Rmu (ORCPT ); Wed, 29 Apr 2020 13:42:50 -0400 Received: from [192.168.42.210] ([93.22.38.239]) by mwinf5d58 with ME id Yhig2200R59bE5H03hig2Q; Wed, 29 Apr 2020 19:42:48 +0200 X-ME-Helo: [192.168.42.210] X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Wed, 29 Apr 2020 19:42:48 +0200 X-ME-IP: 93.22.38.239 Subject: Re: [PATCH] video: fbdev: pxa3xx_gcu: Fix some resource leak in an error handling path in 'pxa3xx_gcu_probe()' To: Dan Carpenter Cc: b.zolnierkie@samsung.com, gregkh@linuxfoundation.org, mpe@ellerman.id.au, zhenzhong.duan@gmail.com, arnd@arndb.de, tglx@linutronix.de, eric.y.miao@gmail.com, daniel@caiaq.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org References: <20200429043438.96212-1-christophe.jaillet@wanadoo.fr> <20200429122538.GO2014@kadam> From: Christophe JAILLET Message-ID: <0db91149-fa85-6ec3-1787-d5effd41a1b9@wanadoo.fr> Date: Wed, 29 Apr 2020 19:42:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200429122538.GO2014@kadam> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 29/04/2020 à 14:25, Dan Carpenter a écrit : > On Wed, Apr 29, 2020 at 06:34:38AM +0200, Christophe JAILLET wrote: >> If an error occurs in the loop where we call 'pxa3xx_gcu_add_buffer()', >> any resource already allocated should be freed. >> >> In order to fix it, add a call to 'pxa3xx_gcu_free_buffers()' in the error >> handling path, as already done in the remove function. >> >> Fixes: 364dbdf3b6c3 ("video: add driver for PXA3xx 2D graphics accelerator") >> Signed-off-by: Christophe JAILLET >> --- >> drivers/video/fbdev/pxa3xx-gcu.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c >> index 4279e13a3b58..68d9c7a681d4 100644 >> --- a/drivers/video/fbdev/pxa3xx-gcu.c >> +++ b/drivers/video/fbdev/pxa3xx-gcu.c >> @@ -675,6 +675,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev) >> >> err_disable_clk: >> clk_disable_unprepare(priv->clk); >> + pxa3xx_gcu_free_buffers(dev, priv); > The error handling in this function makes no sense and is buggy. It > should be that it unwinds in the reverse order from the allocation. The > goto should be "goto free_most_recently_allocated_resource;". Since the > unwind is done in the wrong order it causes a couple bugs. > > These buffers are the last thing which we allocated so they should be > the first thing which we free. In this case, calling > pxa3xx_gcu_free_buffers() before the buffers are allocated is confusing > but harmless. The clk_disable_unprepare() is done on some paths where > the clock was not enabled and that will trigger a WARN() so that's a > bug. Syzcaller will complain and if you have reboot on WARN then it's > annoying. > > The second bug is that we don't deregister the misc device or release > the DMA memory on failure when we allocate the buffers in the loop. > > regards, > dan carpenter > Agreed. I've been a little too fast on this one. I'll update it. Thx for the review. CJ