From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B69C5C43387 for ; Sat, 5 Jan 2019 18:26:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7AC1E22371 for ; Sat, 5 Jan 2019 18:26:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=tronnes.org header.i=@tronnes.org header.b="tVhT5K6E" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726455AbfAES0D (ORCPT ); Sat, 5 Jan 2019 13:26:03 -0500 Received: from smtp.domeneshop.no ([194.63.252.55]:46327 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfAES0D (ORCPT ); Sat, 5 Jan 2019 13:26:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tronnes.org; s=ds201810; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=JGubgKJ77pVkj5c7Fw007EUWEh+lMbJcyBuj1UjEGlo=; b=tVhT5K6ERrmIEaujHvFCTAFlGYljdCd2pMe/k4WLZMqYzozq0tGEOLzyLgNKPihL8E0LvHNwZmOjf1wFnAn0Lnrl0Z5QqFcZP50+UXkeAFOYuO0Az9N3kxOa+ZWRa526OuFnrHSa6bL1w+1zHMFNoAVKrJDHQTgM7Msg3wRNOqjLWK1yU8YqHv1axHbJexWOrF3FEO0OXAptupMYUaHChOoV0A3jF6lXqPt3eVy0Cvrb8oW1uQq5L++qbhOyojTdkyGF+yA0yhZLVfu8wpkXo0IGqYnWmM8KhAn6gjppaSy531XwjGIoVToYBGjc6tAmBGSwzl/VOGsfOaKW7Elp1g==; Received: from 211.81-166-168.customer.lyse.net ([81.166.168.211]:59242 helo=[192.168.10.174]) by smtp.domeneshop.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gfqdz-0002Ry-EI; Sat, 05 Jan 2019 19:25:59 +0100 Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup To: Peter Wu Cc: dri-devel@lists.freedesktop.org, Linus Torvalds , rong.a.chen@intel.com, kraxel@redhat.com, Daniel Vetter , Linux List Kernel Mailing , lkp@01.org References: <20181223004315.GA11455@al> <20181223005507.28328-1-peter@lekensteyn.nl> <20181223231033.GA31596@al> <80d98ab2-dbf8-8d77-e5ca-07995cef0f1b@tronnes.org> <20181224150302.GA2259@al> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: <564896a7-e232-70e2-dd01-fec265f731eb@tronnes.org> Date: Sat, 5 Jan 2019 19:25:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20181224150302.GA2259@al> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 24.12.2018 16.03, skrev Peter Wu: > On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote: >> >> >> Den 24.12.2018 00.10, skrev Peter Wu: >>> On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote: >>>> >>>> >>>> Den 23.12.2018 01.55, skrev Peter Wu: >>>>> After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, >>>>> "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will >>>>> have some effect). After that, drm_fb_helper_initial_config is called >>>>> which may call the "fb_probe" driver callback. >>>>> >>>>> This driver callback may call drm_fb_helper_defio_init (as is done by >>>>> drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs) >>>>> as documented. These are normally cleaned up on exit by >>>>> drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. >>>>> >>>>> If an error occurs after "fb_probe", but before setup is complete, then >>>>> calling just drm_fb_helper_fini will leak resources. This was triggered >>>>> by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"): >>>>> >>>>> [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer >>>>> [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38) >>>>> [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2 >>>>> [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 >>>>> [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 4.20.0-rc7 #1 >>>>> [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 >>>>> ... >>>>> [ 50.023155] Call Trace: >>>>> [ 50.023155] ? bochs_kms_fini+0x1e/0x30 >>>>> [ 50.023155] ? bochs_unload+0x18/0x40 >>>>> >>>>> This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. >>>>> >>>>> Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian >>>>> Link: https://lkml.kernel.org/r/20181223004315.GA11455@al >>>>> Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") >>>>> Reported-by: kernel test robot >>>>> Cc: Noralf Trønnes >>>>> Signed-off-by: Peter Wu >>>>> --- >>>>> drivers/gpu/drm/drm_fb_helper.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c >>>>> index 9d64f874f965..432e0f3b9267 100644 >>>>> --- a/drivers/gpu/drm/drm_fb_helper.c >>>>> +++ b/drivers/gpu/drm/drm_fb_helper.c >>>>> @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev, >>>>> return 0; >>>>> err_drm_fb_helper_fini: >>>>> - drm_fb_helper_fini(fb_helper); >>>>> + drm_fb_helper_fbdev_teardown(dev); >>>> >>>> This change will break the error path for drm_fbdev_generic_setup() >>>> because drm_fb_helper_generic_probe() cleans up on error but doesn't >>>> clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove(). >>> >>> This should probably considered a bug of drm_fb_helper_generic_probe. >>> Ownership of fb_helper should remain with the caller. The caller can >>> detect an error and act accordingly. >>> >>>> My assumption has been that the drm_fb_helper_funcs->fb_probe callback >>>> cleans up its resources on error. Clearly this is not the case for bochs, so >>>> my take on this is that bochsfb_create() needs to clean up on error. >>> >>> That assumption still holds for bochs. The problem is this sequence: >>> - drm_fb_helper_fbdev_setup is called. >>> - fb_probe succeeds (this is crucial). >>> - register_framebuffer fails. >>> - error path of setup is triggered. >>> >>> As fb_helper is fully setup by drivers, the drm_fb_helper core should >>> fully deallocate it again on the error path or else a leak occurs. >>> >>>> Gerd has a patchset that switches bochs over to the generic fbdev >>>> emulation, but ofc that doesn't help with 4.20: >>>> https://patchwork.freedesktop.org/series/54269/ >>> >>> And that does not help with other users of the drm_fb_helper who use >>> functions like drm_fb_helper_defio_init. They will likely run in the >>> same problem. >>> >>> I don't have a way to test tinydrm or other drivers, but if you force >>> register_framebuffer to fail, you should be able to reproduce the >>> problem with drm_fb_helper_generic_probe. >>> >> >> Now I understand. I have looked at the drivers that use drm_fb_helper >> and no one seem to handle the case where register_framebuffer() is >> failing. >> >> Here's what drivers do when drm_fb_helper_initial_config() fails: >> >> Doesn't check: >> amdgpu >> virtio >> >> Calls drm_fb_helper_fini(): >> armada >> ast >> exynos >> gma500 >> hisilicon >> mgag200 >> msm >> nouveau >> omap >> radeon >> rockchip >> tegra >> udl >> bochs - Uses drm_fb_helper_fbdev_setup() >> qxl - Uses drm_fb_helper_fbdev_setup() >> vboxvideo - Uses drm_fb_helper_fbdev_setup() >> >> Might clean up, not sure: >> cirrus >> >> Looks suspicious: >> i915 >> >> I looked at bochs before it switched to drm_fb_helper_fbdev_setup() and >> it also just called drm_fb_helper_fini(). >> >> It looks like you've uncovered something no one has though about (or >> not implemented at least). >> >> It's not just the framebuffer that's not destroyed, the buffer object >> is also leaked. drm_mode_config_cleanup() yells about the framebuffer >> (and frees it), but says nothing about the buffer object. It might be >> that it can't even be made to detect that since some drivers do special >> stuff for the fbdev buffer. >> >> I'll pick up on this and do some testing after the Christmas holidays. > > Thanks, the warning is bad for CI (which uses QEMU), but otherwise it > should not have any effect on regular users so it can wait. > This patch is good as long as it's applied along side the fix[1] to the generic emulation: Reviewed-by: Noralf Trønnes I can apply them both when I get an ack/rb on the other patch. Thanks for fixing this. Noralf. [1] https://patchwork.freedesktop.org/patch/275002/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup Date: Sat, 5 Jan 2019 19:25:53 +0100 Message-ID: <564896a7-e232-70e2-dd01-fec265f731eb@tronnes.org> References: <20181223004315.GA11455@al> <20181223005507.28328-1-peter@lekensteyn.nl> <20181223231033.GA31596@al> <80d98ab2-dbf8-8d77-e5ca-07995cef0f1b@tronnes.org> <20181224150302.GA2259@al> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 675706E096 for ; Sat, 5 Jan 2019 18:26:02 +0000 (UTC) In-Reply-To: <20181224150302.GA2259@al> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Peter Wu Cc: lkp@01.org, rong.a.chen@intel.com, Daniel Vetter , Linux List Kernel Mailing , dri-devel@lists.freedesktop.org, kraxel@redhat.com, Linus Torvalds List-Id: dri-devel@lists.freedesktop.org CgpEZW4gMjQuMTIuMjAxOCAxNi4wMywgc2tyZXYgUGV0ZXIgV3U6Cj4gT24gTW9uLCBEZWMgMjQs IDIwMTggYXQgMDM6NTI6NTVQTSArMDEwMCwgTm9yYWxmIFRyw7hubmVzIHdyb3RlOgo+Pgo+Pgo+ PiBEZW4gMjQuMTIuMjAxOCAwMC4xMCwgc2tyZXYgUGV0ZXIgV3U6Cj4+PiBPbiBTdW4sIERlYyAy MywgMjAxOCBhdCAwMjo1NTo1MlBNICswMTAwLCBOb3JhbGYgVHLDuG5uZXMgd3JvdGU6Cj4+Pj4K Pj4+Pgo+Pj4+IERlbiAyMy4xMi4yMDE4IDAxLjU1LCBza3JldiBQZXRlciBXdToKPj4+Pj4gQWZ0 ZXIgZHJtX2ZiX2hlbHBlcl9mYmRldl9zZXR1cCBjYWxscyBkcm1fZmJfaGVscGVyX2luaXQsCj4+ Pj4+ICJkZXYtPmZiX2hlbHBlciIgd2lsbCBiZSBpbml0aWFsaXplZCAoYW5kIHRodXMgZHJtX2Zi X2hlbHBlcl9maW5pIHdpbGwKPj4+Pj4gaGF2ZSBzb21lIGVmZmVjdCkuIEFmdGVyIHRoYXQsIGRy bV9mYl9oZWxwZXJfaW5pdGlhbF9jb25maWcgaXMgY2FsbGVkCj4+Pj4+IHdoaWNoIG1heSBjYWxs IHRoZSAiZmJfcHJvYmUiIGRyaXZlciBjYWxsYmFjay4KPj4+Pj4KPj4+Pj4gVGhpcyBkcml2ZXIg Y2FsbGJhY2sgbWF5IGNhbGwgZHJtX2ZiX2hlbHBlcl9kZWZpb19pbml0IChhcyBpcyBkb25lIGJ5 Cj4+Pj4+IGRybV9mYl9oZWxwZXJfZ2VuZXJpY19wcm9iZSkgb3Igc2V0IGEgZnJhbWVidWZmZXIg KGFzIGlzIGRvbmUgYnkgYm9jaHMpCj4+Pj4+IGFzIGRvY3VtZW50ZWQuIFRoZXNlIGFyZSBub3Jt YWxseSBjbGVhbmVkIHVwIG9uIGV4aXQgYnkKPj4+Pj4gZHJtX2ZiX2hlbHBlcl9mYmRldl90ZWFy ZG93biB3aGljaCBhbHNvIGNhbGxzIGRybV9mYl9oZWxwZXJfZmluaS4KPj4+Pj4KPj4+Pj4gSWYg YW4gZXJyb3Igb2NjdXJzIGFmdGVyICJmYl9wcm9iZSIsIGJ1dCBiZWZvcmUgc2V0dXAgaXMgY29t cGxldGUsIHRoZW4KPj4+Pj4gY2FsbGluZyBqdXN0IGRybV9mYl9oZWxwZXJfZmluaSB3aWxsIGxl YWsgcmVzb3VyY2VzLiBUaGlzIHdhcyB0cmlnZ2VyZWQKPj4+Pj4gYnkgZGYyMDUyY2M5MjIgKCJi b2NoczogY29udmVydCB0byBkcm1fZmJfaGVscGVyX2ZiZGV2X3NldHVwL3RlYXJkb3duIik6Cj4+ Pj4+Cj4+Pj4+ICAgICAgICBbICAgNTAuMDA4MDMwXSBib2Noc2RybWZiOiBlbmFibGUgQ09ORklH X0ZCX0xJVFRMRV9FTkRJQU4gdG8gc3VwcG9ydCB0aGlzIGZyYW1lYnVmZmVyCj4+Pj4+ICAgICAg ICBbICAgNTAuMDA5NDM2XSBib2Nocy1kcm0gMDAwMDowMDowMi4wOiBbZHJtOmRybV9mYl9oZWxw ZXJfZmJkZXZfc2V0dXBdICpFUlJPUiogZmJkZXY6IEZhaWxlZCB0byBzZXQgY29uZmlndXJhdGlv biAocmV0PS0zOCkKPj4+Pj4gICAgICAgIFsgICA1MC4wMTE0NTZdIFtkcm1dIEluaXRpYWxpemVk IGJvY2hzLWRybSAxLjAuMCAyMDEzMDkyNSBmb3IgMDAwMDowMDowMi4wIG9uIG1pbm9yIDIKPj4+ Pj4gICAgICAgIFsgICA1MC4wMTM2MDRdIFdBUk5JTkc6IENQVTogMSBQSUQ6IDEgYXQgZHJpdmVy cy9ncHUvZHJtL2RybV9tb2RlX2NvbmZpZy5jOjQ3NyBkcm1fbW9kZV9jb25maWdfY2xlYW51cCsw eDI4MC8weDJhMAo+Pj4+PiAgICAgICAgWyAgIDUwLjAxNjE3NV0gQ1BVOiAxIFBJRDogMSBDb21t OiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgICAgICAgICBUIDQuMjAuMC1yYzcgIzEKPj4+ Pj4gICAgICAgIFsgICA1MC4wMTc3MzJdIEVJUDogZHJtX21vZGVfY29uZmlnX2NsZWFudXArMHgy ODAvMHgyYTAKPj4+Pj4gICAgICAgIC4uLgo+Pj4+PiAgICAgICAgWyAgIDUwLjAyMzE1NV0gQ2Fs bCBUcmFjZToKPj4+Pj4gICAgICAgIFsgICA1MC4wMjMxNTVdICA/IGJvY2hzX2ttc19maW5pKzB4 MWUvMHgzMAo+Pj4+PiAgICAgICAgWyAgIDUwLjAyMzE1NV0gID8gYm9jaHNfdW5sb2FkKzB4MTgv MHg0MAo+Pj4+Pgo+Pj4+PiBUaGlzIGNhbiBiZSByZXByb2R1Y2VkIHdpdGggUUVNVSBhbmQgQ09O RklHX0ZCX0xJVFRMRV9FTkRJQU49bi4KPj4+Pj4KPj4+Pj4gTGluazogaHR0cHM6Ly9sa21sLmtl cm5lbC5vcmcvci8yMDE4MTIyMTA4MzIyNi5HSTIzMzMyQHNoYW8yLWRlYmlhbgo+Pj4+PiBMaW5r OiBodHRwczovL2xrbWwua2VybmVsLm9yZy9yLzIwMTgxMjIzMDA0MzE1LkdBMTE0NTVAYWwKPj4+ Pj4gRml4ZXM6IDg3NDEyMTYzOTZiMiAoImRybS9mYi1oZWxwZXI6IEFkZCBkcm1fZmJfaGVscGVy X2ZiZGV2X3NldHVwL3RlYXJkb3duKCkiKQo+Pj4+PiBSZXBvcnRlZC1ieToga2VybmVsIHRlc3Qg cm9ib3QgPHJvbmcuYS5jaGVuQGludGVsLmNvbT4KPj4+Pj4gQ2M6IE5vcmFsZiBUcsO4bm5lcyA8 bm9yYWxmQHRyb25uZXMub3JnPgo+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBQZXRlciBXdSA8cGV0ZXJA bGVrZW5zdGV5bi5ubD4KPj4+Pj4gLS0tCj4+Pj4+ICAgICBkcml2ZXJzL2dwdS9kcm0vZHJtX2Zi X2hlbHBlci5jIHwgMiArLQo+Pj4+PiAgICAgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCsp LCAxIGRlbGV0aW9uKC0pCj4+Pj4+Cj4+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0v ZHJtX2ZiX2hlbHBlci5jIGIvZHJpdmVycy9ncHUvZHJtL2RybV9mYl9oZWxwZXIuYwo+Pj4+PiBp bmRleCA5ZDY0Zjg3NGY5NjUuLjQzMmUwZjNiOTI2NyAxMDA2NDQKPj4+Pj4gLS0tIGEvZHJpdmVy cy9ncHUvZHJtL2RybV9mYl9oZWxwZXIuYwo+Pj4+PiArKysgYi9kcml2ZXJzL2dwdS9kcm0vZHJt X2ZiX2hlbHBlci5jCj4+Pj4+IEBAIC0yODYwLDcgKzI4NjAsNyBAQCBpbnQgZHJtX2ZiX2hlbHBl cl9mYmRldl9zZXR1cChzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LAo+Pj4+PiAgICAgCXJldHVybiAw Owo+Pj4+PiAgICAgZXJyX2RybV9mYl9oZWxwZXJfZmluaToKPj4+Pj4gLQlkcm1fZmJfaGVscGVy X2ZpbmkoZmJfaGVscGVyKTsKPj4+Pj4gKwlkcm1fZmJfaGVscGVyX2ZiZGV2X3RlYXJkb3duKGRl dik7Cj4+Pj4KPj4+PiBUaGlzIGNoYW5nZSB3aWxsIGJyZWFrIHRoZSBlcnJvciBwYXRoIGZvciBk cm1fZmJkZXZfZ2VuZXJpY19zZXR1cCgpCj4+Pj4gYmVjYXVzZSBkcm1fZmJfaGVscGVyX2dlbmVy aWNfcHJvYmUoKSBjbGVhbnMgdXAgb24gZXJyb3IgYnV0IGRvZXNuJ3QKPj4+PiBjbGVhciBkcm1f ZmJfaGVscGVyLT5mYiByZXN1bHRpbmcgaW4gYSBkb3VibGUgZHJtX2ZyYW1lYnVmZmVyX3JlbW92 ZSgpLgo+Pj4KPj4+IFRoaXMgc2hvdWxkIHByb2JhYmx5IGNvbnNpZGVyZWQgYSBidWcgb2YgZHJt X2ZiX2hlbHBlcl9nZW5lcmljX3Byb2JlLgo+Pj4gT3duZXJzaGlwIG9mIGZiX2hlbHBlciBzaG91 bGQgcmVtYWluIHdpdGggdGhlIGNhbGxlci4gVGhlIGNhbGxlciBjYW4KPj4+IGRldGVjdCBhbiBl cnJvciBhbmQgYWN0IGFjY29yZGluZ2x5Lgo+Pj4KPj4+PiBNeSBhc3N1bXB0aW9uIGhhcyBiZWVu IHRoYXQgdGhlIGRybV9mYl9oZWxwZXJfZnVuY3MtPmZiX3Byb2JlIGNhbGxiYWNrCj4+Pj4gY2xl YW5zIHVwIGl0cyByZXNvdXJjZXMgb24gZXJyb3IuIENsZWFybHkgdGhpcyBpcyBub3QgdGhlIGNh c2UgZm9yIGJvY2hzLCBzbwo+Pj4+IG15IHRha2Ugb24gdGhpcyBpcyB0aGF0IGJvY2hzZmJfY3Jl YXRlKCkgbmVlZHMgdG8gY2xlYW4gdXAgb24gZXJyb3IuCj4+Pgo+Pj4gVGhhdCBhc3N1bXB0aW9u IHN0aWxsIGhvbGRzIGZvciBib2Nocy4gVGhlIHByb2JsZW0gaXMgdGhpcyBzZXF1ZW5jZToKPj4+ IC0gZHJtX2ZiX2hlbHBlcl9mYmRldl9zZXR1cCBpcyBjYWxsZWQuCj4+PiAtIGZiX3Byb2JlIHN1 Y2NlZWRzICh0aGlzIGlzIGNydWNpYWwpLgo+Pj4gLSByZWdpc3Rlcl9mcmFtZWJ1ZmZlciBmYWls cy4KPj4+IC0gZXJyb3IgcGF0aCBvZiBzZXR1cCBpcyB0cmlnZ2VyZWQuCj4+Pgo+Pj4gQXMgZmJf aGVscGVyIGlzIGZ1bGx5IHNldHVwIGJ5IGRyaXZlcnMsIHRoZSBkcm1fZmJfaGVscGVyIGNvcmUg c2hvdWxkCj4+PiBmdWxseSBkZWFsbG9jYXRlIGl0IGFnYWluIG9uIHRoZSBlcnJvciBwYXRoIG9y IGVsc2UgYSBsZWFrIG9jY3Vycy4KPj4+Cj4+Pj4gR2VyZCBoYXMgYSBwYXRjaHNldCB0aGF0IHN3 aXRjaGVzIGJvY2hzIG92ZXIgdG8gdGhlIGdlbmVyaWMgZmJkZXYKPj4+PiBlbXVsYXRpb24sIGJ1 dCBvZmMgdGhhdCBkb2Vzbid0IGhlbHAgd2l0aCA0LjIwOgo+Pj4+IGh0dHBzOi8vcGF0Y2h3b3Jr LmZyZWVkZXNrdG9wLm9yZy9zZXJpZXMvNTQyNjkvCj4+Pgo+Pj4gQW5kIHRoYXQgZG9lcyBub3Qg aGVscCB3aXRoIG90aGVyIHVzZXJzIG9mIHRoZSBkcm1fZmJfaGVscGVyIHdobyB1c2UKPj4+IGZ1 bmN0aW9ucyBsaWtlIGRybV9mYl9oZWxwZXJfZGVmaW9faW5pdC4gVGhleSB3aWxsIGxpa2VseSBy dW4gaW4gdGhlCj4+PiBzYW1lIHByb2JsZW0uCj4+Pgo+Pj4gSSBkb24ndCBoYXZlIGEgd2F5IHRv IHRlc3QgdGlueWRybSBvciBvdGhlciBkcml2ZXJzLCBidXQgaWYgeW91IGZvcmNlCj4+PiByZWdp c3Rlcl9mcmFtZWJ1ZmZlciB0byBmYWlsLCB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gcmVwcm9kdWNl IHRoZQo+Pj4gcHJvYmxlbSB3aXRoIGRybV9mYl9oZWxwZXJfZ2VuZXJpY19wcm9iZS4KPj4+Cj4+ Cj4+IE5vdyBJIHVuZGVyc3RhbmQuIEkgaGF2ZSBsb29rZWQgYXQgdGhlIGRyaXZlcnMgdGhhdCB1 c2UgZHJtX2ZiX2hlbHBlcgo+PiBhbmQgbm8gb25lIHNlZW0gdG8gaGFuZGxlIHRoZSBjYXNlIHdo ZXJlIHJlZ2lzdGVyX2ZyYW1lYnVmZmVyKCkgaXMKPj4gZmFpbGluZy4KPj4KPj4gSGVyZSdzIHdo YXQgZHJpdmVycyBkbyB3aGVuIGRybV9mYl9oZWxwZXJfaW5pdGlhbF9jb25maWcoKSBmYWlsczoK Pj4KPj4gRG9lc24ndCBjaGVjazoKPj4gYW1kZ3B1Cj4+IHZpcnRpbwo+Pgo+PiBDYWxscyBkcm1f ZmJfaGVscGVyX2ZpbmkoKToKPj4gYXJtYWRhCj4+IGFzdAo+PiBleHlub3MKPj4gZ21hNTAwCj4+ IGhpc2lsaWNvbgo+PiBtZ2FnMjAwCj4+IG1zbQo+PiBub3V2ZWF1Cj4+IG9tYXAKPj4gcmFkZW9u Cj4+IHJvY2tjaGlwCj4+IHRlZ3JhCj4+IHVkbAo+PiBib2NocyAtIFVzZXMgZHJtX2ZiX2hlbHBl cl9mYmRldl9zZXR1cCgpCj4+IHF4bCAtIFVzZXMgZHJtX2ZiX2hlbHBlcl9mYmRldl9zZXR1cCgp Cj4+IHZib3h2aWRlbyAtIFVzZXMgZHJtX2ZiX2hlbHBlcl9mYmRldl9zZXR1cCgpCj4+Cj4+IE1p Z2h0IGNsZWFuIHVwLCBub3Qgc3VyZToKPj4gY2lycnVzCj4+Cj4+IExvb2tzIHN1c3BpY2lvdXM6 Cj4+IGk5MTUKPj4KPj4gSSBsb29rZWQgYXQgYm9jaHMgYmVmb3JlIGl0IHN3aXRjaGVkIHRvIGRy bV9mYl9oZWxwZXJfZmJkZXZfc2V0dXAoKSBhbmQKPj4gaXQgYWxzbyBqdXN0IGNhbGxlZCBkcm1f ZmJfaGVscGVyX2ZpbmkoKS4KPj4KPj4gSXQgbG9va3MgbGlrZSB5b3UndmUgdW5jb3ZlcmVkIHNv bWV0aGluZyBubyBvbmUgaGFzIHRob3VnaCBhYm91dCAob3IKPj4gbm90IGltcGxlbWVudGVkIGF0 IGxlYXN0KS4KPj4KPj4gSXQncyBub3QganVzdCB0aGUgZnJhbWVidWZmZXIgdGhhdCdzIG5vdCBk ZXN0cm95ZWQsIHRoZSBidWZmZXIgb2JqZWN0Cj4+IGlzIGFsc28gbGVha2VkLiBkcm1fbW9kZV9j b25maWdfY2xlYW51cCgpIHllbGxzIGFib3V0IHRoZSBmcmFtZWJ1ZmZlcgo+PiAoYW5kIGZyZWVz IGl0KSwgYnV0IHNheXMgbm90aGluZyBhYm91dCB0aGUgYnVmZmVyIG9iamVjdC4gSXQgbWlnaHQg YmUKPj4gdGhhdCBpdCBjYW4ndCBldmVuIGJlIG1hZGUgdG8gZGV0ZWN0IHRoYXQgc2luY2Ugc29t ZSBkcml2ZXJzIGRvIHNwZWNpYWwKPj4gc3R1ZmYgZm9yIHRoZSBmYmRldiBidWZmZXIuCj4+Cj4+ IEknbGwgcGljayB1cCBvbiB0aGlzIGFuZCBkbyBzb21lIHRlc3RpbmcgYWZ0ZXIgdGhlIENocmlz dG1hcyBob2xpZGF5cy4KPiAKPiBUaGFua3MsIHRoZSB3YXJuaW5nIGlzIGJhZCBmb3IgQ0kgKHdo aWNoIHVzZXMgUUVNVSksIGJ1dCBvdGhlcndpc2UgaXQKPiBzaG91bGQgbm90IGhhdmUgYW55IGVm ZmVjdCBvbiByZWd1bGFyIHVzZXJzIHNvIGl0IGNhbiB3YWl0Lgo+IAoKVGhpcyBwYXRjaCBpcyBn b29kIGFzIGxvbmcgYXMgaXQncyBhcHBsaWVkIGFsb25nIHNpZGUgdGhlIGZpeFsxXSB0byB0aGUg CmdlbmVyaWMgZW11bGF0aW9uOgoKUmV2aWV3ZWQtYnk6IE5vcmFsZiBUcsO4bm5lcyA8bm9yYWxm QHRyb25uZXMub3JnPgoKSSBjYW4gYXBwbHkgdGhlbSBib3RoIHdoZW4gSSBnZXQgYW4gYWNrL3Ji IG9uIHRoZSBvdGhlciBwYXRjaC4KClRoYW5rcyBmb3IgZml4aW5nIHRoaXMuCgpOb3JhbGYuCgpb MV0gaHR0cHM6Ly9wYXRjaHdvcmsuZnJlZWRlc2t0b3Aub3JnL3BhdGNoLzI3NTAwMi8KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxp bmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJl ZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3533911084548563784==" MIME-Version: 1.0 From: Noralf Trønnes To: lkp@lists.01.org Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup Date: Sat, 05 Jan 2019 19:25:53 +0100 Message-ID: <564896a7-e232-70e2-dd01-fec265f731eb@tronnes.org> In-Reply-To: <20181224150302.GA2259@al> List-Id: --===============3533911084548563784== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Den 24.12.2018 16.03, skrev Peter Wu: > On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Tr=C3=B8nnes wrote: >> >> >> Den 24.12.2018 00.10, skrev Peter Wu: >>> On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Tr=C3=B8nnes wrote: >>>> >>>> >>>> Den 23.12.2018 01.55, skrev Peter Wu: >>>>> After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, >>>>> "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will >>>>> have some effect). After that, drm_fb_helper_initial_config is called >>>>> which may call the "fb_probe" driver callback. >>>>> >>>>> This driver callback may call drm_fb_helper_defio_init (as is done by >>>>> drm_fb_helper_generic_probe) or set a framebuffer (as is done by boch= s) >>>>> as documented. These are normally cleaned up on exit by >>>>> drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. >>>>> >>>>> If an error occurs after "fb_probe", but before setup is complete, th= en >>>>> calling just drm_fb_helper_fini will leak resources. This was trigger= ed >>>>> by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown= "): >>>>> >>>>> [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to s= upport this framebuffer >>>>> [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbde= v_setup] *ERROR* fbdev: Failed to set configuration (ret=3D-38) >>>>> [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for = 0000:00:02.0 on minor 2 >>>>> [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_m= ode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 >>>>> [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G = T 4.20.0-rc7 #1 >>>>> [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 >>>>> ... >>>>> [ 50.023155] Call Trace: >>>>> [ 50.023155] ? bochs_kms_fini+0x1e/0x30 >>>>> [ 50.023155] ? bochs_unload+0x18/0x40 >>>>> >>>>> This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=3Dn. >>>>> >>>>> Link: https://lkml.kernel.org/r/20181221083226.GI23332(a)shao2-debian >>>>> Link: https://lkml.kernel.org/r/20181223004315.GA11455(a)al >>>>> Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/te= ardown()") >>>>> Reported-by: kernel test robot >>>>> Cc: Noralf Tr=C3=B8nnes >>>>> Signed-off-by: Peter Wu >>>>> --- >>>>> drivers/gpu/drm/drm_fb_helper.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb= _helper.c >>>>> index 9d64f874f965..432e0f3b9267 100644 >>>>> --- a/drivers/gpu/drm/drm_fb_helper.c >>>>> +++ b/drivers/gpu/drm/drm_fb_helper.c >>>>> @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device= *dev, >>>>> return 0; >>>>> err_drm_fb_helper_fini: >>>>> - drm_fb_helper_fini(fb_helper); >>>>> + drm_fb_helper_fbdev_teardown(dev); >>>> >>>> This change will break the error path for drm_fbdev_generic_setup() >>>> because drm_fb_helper_generic_probe() cleans up on error but doesn't >>>> clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove(). >>> >>> This should probably considered a bug of drm_fb_helper_generic_probe. >>> Ownership of fb_helper should remain with the caller. The caller can >>> detect an error and act accordingly. >>> >>>> My assumption has been that the drm_fb_helper_funcs->fb_probe callback >>>> cleans up its resources on error. Clearly this is not the case for boc= hs, so >>>> my take on this is that bochsfb_create() needs to clean up on error. >>> >>> That assumption still holds for bochs. The problem is this sequence: >>> - drm_fb_helper_fbdev_setup is called. >>> - fb_probe succeeds (this is crucial). >>> - register_framebuffer fails. >>> - error path of setup is triggered. >>> >>> As fb_helper is fully setup by drivers, the drm_fb_helper core should >>> fully deallocate it again on the error path or else a leak occurs. >>> >>>> Gerd has a patchset that switches bochs over to the generic fbdev >>>> emulation, but ofc that doesn't help with 4.20: >>>> https://patchwork.freedesktop.org/series/54269/ >>> >>> And that does not help with other users of the drm_fb_helper who use >>> functions like drm_fb_helper_defio_init. They will likely run in the >>> same problem. >>> >>> I don't have a way to test tinydrm or other drivers, but if you force >>> register_framebuffer to fail, you should be able to reproduce the >>> problem with drm_fb_helper_generic_probe. >>> >> >> Now I understand. I have looked at the drivers that use drm_fb_helper >> and no one seem to handle the case where register_framebuffer() is >> failing. >> >> Here's what drivers do when drm_fb_helper_initial_config() fails: >> >> Doesn't check: >> amdgpu >> virtio >> >> Calls drm_fb_helper_fini(): >> armada >> ast >> exynos >> gma500 >> hisilicon >> mgag200 >> msm >> nouveau >> omap >> radeon >> rockchip >> tegra >> udl >> bochs - Uses drm_fb_helper_fbdev_setup() >> qxl - Uses drm_fb_helper_fbdev_setup() >> vboxvideo - Uses drm_fb_helper_fbdev_setup() >> >> Might clean up, not sure: >> cirrus >> >> Looks suspicious: >> i915 >> >> I looked at bochs before it switched to drm_fb_helper_fbdev_setup() and >> it also just called drm_fb_helper_fini(). >> >> It looks like you've uncovered something no one has though about (or >> not implemented at least). >> >> It's not just the framebuffer that's not destroyed, the buffer object >> is also leaked. drm_mode_config_cleanup() yells about the framebuffer >> (and frees it), but says nothing about the buffer object. It might be >> that it can't even be made to detect that since some drivers do special >> stuff for the fbdev buffer. >> >> I'll pick up on this and do some testing after the Christmas holidays. > = > Thanks, the warning is bad for CI (which uses QEMU), but otherwise it > should not have any effect on regular users so it can wait. > = This patch is good as long as it's applied along side the fix[1] to the = generic emulation: Reviewed-by: Noralf Tr=C3=B8nnes I can apply them both when I get an ack/rb on the other patch. Thanks for fixing this. Noralf. [1] https://patchwork.freedesktop.org/patch/275002/ --===============3533911084548563784==--