All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Peter Wu <peter@lekensteyn.nl>, dri-devel@lists.freedesktop.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	rong.a.chen@intel.com, kraxel@redhat.com,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	lkp@01.org
Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Date: Sun, 23 Dec 2018 14:55:52 +0100	[thread overview]
Message-ID: <ad4be2e7-b53c-97b5-7029-83f4017e4643@tronnes.org> (raw)
In-Reply-To: <20181223005507.28328-1-peter@lekensteyn.nl>



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 <rong.a.chen@intel.com>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
>   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().

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.

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/

Noralf.

>   
>   	return ret;
>   }
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Peter Wu <peter@lekensteyn.nl>, dri-devel@lists.freedesktop.org
Cc: rong.a.chen@intel.com, Daniel Vetter <daniel.vetter@ffwll.ch>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	kraxel@redhat.com, lkp@01.org
Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Date: Sun, 23 Dec 2018 14:55:52 +0100	[thread overview]
Message-ID: <ad4be2e7-b53c-97b5-7029-83f4017e4643@tronnes.org> (raw)
In-Reply-To: <20181223005507.28328-1-peter@lekensteyn.nl>



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 <rong.a.chen@intel.com>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
>   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().

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.

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/

Noralf.

>   
>   	return ret;
>   }
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Noralf Trønnes <noralf@tronnes.org>
To: lkp@lists.01.org
Subject: Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Date: Sun, 23 Dec 2018 14:55:52 +0100	[thread overview]
Message-ID: <ad4be2e7-b53c-97b5-7029-83f4017e4643@tronnes.org> (raw)
In-Reply-To: <20181223005507.28328-1-peter@lekensteyn.nl>

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]



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(a)shao2-debian
> Link: https://lkml.kernel.org/r/20181223004315.GA11455(a)al
> Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
> Reported-by: kernel test robot <rong.a.chen@intel.com>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
>   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().

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.

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/

Noralf.

>   
>   	return ret;
>   }
> 

  reply	other threads:[~2018-12-23 14:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21  8:32 [LKP] [bochs] df2052cc92: WARNING:at_drivers/gpu/drm/drm_mode_config.c:#drm_mode_config_cleanup kernel test robot
2018-12-21  8:32 ` kernel test robot
2018-12-21 19:25 ` [LKP] " Linus Torvalds
2018-12-21 19:25   ` Linus Torvalds
2018-12-23  0:43   ` [LKP] " Peter Wu
2018-12-23  0:43     ` Peter Wu
2018-12-23  0:43     ` [LKP] " Peter Wu
2018-12-23  0:55     ` [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup Peter Wu
2018-12-23  0:55       ` Peter Wu
2018-12-23  0:55       ` Peter Wu
2018-12-23 13:55       ` Noralf Trønnes [this message]
2018-12-23 13:55         ` Noralf Trønnes
2018-12-23 13:55         ` Noralf Trønnes
2018-12-23 23:10         ` Peter Wu
2018-12-23 23:10           ` Peter Wu
2018-12-23 23:10           ` Peter Wu
2018-12-24 14:52           ` Noralf Trønnes
2018-12-24 14:52             ` Noralf Trønnes
2018-12-24 14:52             ` Noralf Trønnes
2018-12-24 15:03             ` Peter Wu
2018-12-24 15:03               ` Peter Wu
2018-12-24 15:03               ` Peter Wu
2019-01-05 18:25               ` Noralf Trønnes
2019-01-05 18:25                 ` Noralf Trønnes
2019-01-05 18:25                 ` Noralf Trønnes
2019-01-08 17:55                 ` Noralf Trønnes
2019-01-08 17:55                   ` Noralf Trønnes
2019-01-08 17:55                   ` Noralf Trønnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad4be2e7-b53c-97b5-7029-83f4017e4643@tronnes.org \
    --to=noralf@tronnes.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=peter@lekensteyn.nl \
    --cc=rong.a.chen@intel.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.