linux-kernel - Re: [RFC PATCH] vmwgfx: Fix assignment in vmw_framebuffer_create

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F22BA91.9020406@vmware.com>
Date:	Fri, 27 Jan 2012 15:54:09 +0100
From:	Thomas Hellstrom <thellstrom@...are.com>
To:	Jakob Bornecrantz <jakob@...are.com>
CC:	airlied@...ux.ie, airlied@...hat.com,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	joe Perches <joe@...ches.com>, Ryan Mallon <rmallon@...il.com>
Subject: Re: [RFC PATCH] vmwgfx: Fix assignment in vmw_framebuffer_create_handle

On 01/27/2012 03:41 PM, Jakob Bornecrantz wrote:
> ----- Original Message -----
>> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
>>> I was asking around and this seems to only be used by X when it
>>> starts and we want to preserve the contents of the screen. That
>>> feature is implemented by the X driver. So we need to figure how we
>>> want to solve it.
>>>
>>> Either way this fix should probably go into this RC series, not
>>> sure if we need to send this to stable, since we are not leaking
>>> data to userspace (check drm_mode_getfb), but we might as well.
>>>
>>> Reviewed-by: Jakob Bornecrantz<jakob@...are.com>
>> But shouldn't we return the *real* handle. Not 0??
> Yeah, you are right. Not sure we have user_handle in the stable
> kernels tho.
We do AFAICT.

>
> We need to change not only the X driver but also all the other
> userspace components since at least libkms doesn't create shared
> buffers.
Libkms is not used anymore, at least not in the X server driver.

>   And if the thing that is running before X is using fbdev
> this wont do much good either since fbdev is not backed by a
> fb in the way other drivers do it.
OK. Then I suggest we just return 0 here, and go ahead with the current 
patch, and
when we've figured out how to do the handover, we bump kernel minor and
return a proper handle. Does that sound OK?

/Thomas


>
> Cheers, Jakob.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/