lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 17 Oct 2022 21:16:03 +0200
From:   Johan Jonker <jbx6244@...il.com>
To:     John Keeping <john@...anate.com>,
        Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Heiko Stuebner <heiko@...ech.de>, dri-devel@...ts.freedesktop.org,
        Sandy Huang <hjc@...k-chips.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org
Subject: Re: [BUG] [PATCH] drm/rockchip: use generic fbdev setup



On 10/17/22 21:00, John Keeping wrote:
> On Mon, Oct 17, 2022 at 08:30:23PM +0200, Johan Jonker wrote:
>>
>>
>> On 10/17/22 13:29, Heiko Stuebner wrote:
>>> Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
>>>> Hi Johan,
>>>>
>>>> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
>>>>> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a SoC.
>>>>> Would you like to contribute to fix this issue?
>>>>> The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init did is not true!
>>>>> A revert makes it work again.
>>>>
>>
>>>> It looks like there are 3 different ways to end up with -ENOMEM here,
>>>> can you track down whether you're hitting one of the cases in
>>>> rockchip_gem_prime_vmap() or if it's the iosys_map_is_null case in
>>>> drm_gem_vmap()?
>>
>> It looks like it comes from rockchip_gem_prime_vmap() second return (2).
>>
>>
>> 	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) {
>>
>> ////////////////
>>
>> 		printk("FBDEV rockchip_gem_prime_vmap 2");
>>
>> ////////////////
>> 		return -ENOMEM;
>> 	}
> 
> Ah-ha, Heiko was right that this is because the no-iommu path is broken
> as a result of switching to the generic fbdev code.
> 
> This patch should fix it, but I wonder if Thomas has any ideas about a
> better way to handle this since it feels a bit hacky to special-case the
> fb_helper inside the GEM code:

The penguin is back on screen. Thanks!

> 
> -- >8 --
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index 614e97aaac80..da8a69953706 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -364,9 +364,12 @@ rockchip_gem_create_with_handle(struct drm_file *file_priv,
>  {
>  	struct rockchip_gem_object *rk_obj;
>  	struct drm_gem_object *obj;
> +	bool is_framebuffer;
>  	int ret;
>  
> -	rk_obj = rockchip_gem_create_object(drm, size, false);
> +	is_framebuffer = drm->fb_helper && file_priv == drm->fb_helper->client.file;
> +
> +	rk_obj = rockchip_gem_create_object(drm, size, is_framebuffer);
>  	if (IS_ERR(rk_obj))
>  		return ERR_CAST(rk_obj);
> -- 8< -- 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ