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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <59e7ade50d352fd3fe9ab6b6f9fe1322@agner.ch>
Date:   Thu, 23 Mar 2017 17:42:28 -0700
From:   Stefan Agner <stefan@...er.ch>
To:     Michel Dänzer <michel@...nzer.net>
Cc:     dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Daniel Stone <daniel@...ishbar.org>
Subject: Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) <
 fb->width/height again

On 2017-03-23 01:53, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daenzer@....com>
> 
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.

When changing resolution a regular fbdev driver also changes display
timing accordingly (fb_var_screeninfo contains timings as well). The
fbdev emulation layer does not change timing, so that was the idea why
my patch also rejected any kind of change to the resolution... In the
end it is really a definition of the semantics of that userspace API
(FBIOPUT_VSCREENINFO) and how true DRM emulates them...

Using less of the available framebuffer seems safe, especially since
line width is handled by pitch/line_length.

As far as I remember my case was a fbdev application which fiddled with
bpp/depth, which lead to a totally messed up outcome... So my use case
will still be fine with your change.

I am ok with relaxing that again, so from my side:
Acked-by: Stefan Agner <stefan@...er.ch>

--
Stefan


> 
> The depths must match though, so keep the != test for that.
> 
> Also update the DRM_DEBUG output to be slightly more accurate, this
> doesn't only affect requests from userspace.
> 
> Bugzilla: https://bugs.freedesktop.org/99841
> Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev")
> Signed-off-by: Michel Dänzer <michel.daenzer@....com>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6d4d9700734..324a688b3f30 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1260,9 +1260,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
>  	 * to KMS, hence fail if different settings are requested.
>  	 */
>  	if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> -	    var->xres != fb->width || var->yres != fb->height ||
> -	    var->xres_virtual != fb->width || var->yres_virtual != fb->height) {
> -		DRM_DEBUG("fb userspace requested width/height/bpp different than
> current fb "
> +	    var->xres > fb->width || var->yres > fb->height ||
> +	    var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> +		DRM_DEBUG("fb requested width/height/bpp can't fit in current fb "
>  			  "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
>  			  var->xres, var->yres, var->bits_per_pixel,
>  			  var->xres_virtual, var->yres_virtual,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ