From: Javier Martinez Canillas <javierm@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
Date: Wed, 05 Apr 2023 18:27:17 +0200 [thread overview]
Message-ID: <87ilea9twa.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <ZC12aR9ddp3j/3dL@phenom.ffwll.local>
Daniel Vetter <daniel@ffwll.ch> writes:
[...]
>>
>> but only the 'var->xres > fb->width || var->yres > fb->height' from the
>> conditions checked could be false after your __fill_var() call above.
>>
>> You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
>> fb->width' and 'var->yres_virtual > fb->height' checks I believe since
>> those will always be true.
>
> The __fill_var is after this. I'm honestly not sure what the exact
Ah, your patch adds it after that indeed. Please ignore my comment then.
> semantics are supposed to be, but essentially if userspace asks for too
> big virtual size, we reject it. And for anything else we then tell it
> (with __fill_var) how big the actually available space is.
>
> What I'm wondering now is whether too small x/yres won't lead to problems
> of some sorts ... For multi-screen we set the virtual size to be big
> enough for all crtc, and then just set x/yres to be the smallest output.
> That way fbcon knows to only draw as much as is visible on all screens.
> But if you then pan that too much, the bigger screens might not have a big
> enough buffer anymore and things fail (but shouldn't).
>
> Not sure how to fix that tbh.
Would this be a problem in practice?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
Date: Wed, 05 Apr 2023 18:27:17 +0200 [thread overview]
Message-ID: <87ilea9twa.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <ZC12aR9ddp3j/3dL@phenom.ffwll.local>
Daniel Vetter <daniel@ffwll.ch> writes:
[...]
>>
>> but only the 'var->xres > fb->width || var->yres > fb->height' from the
>> conditions checked could be false after your __fill_var() call above.
>>
>> You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
>> fb->width' and 'var->yres_virtual > fb->height' checks I believe since
>> those will always be true.
>
> The __fill_var is after this. I'm honestly not sure what the exact
Ah, your patch adds it after that indeed. Please ignore my comment then.
> semantics are supposed to be, but essentially if userspace asks for too
> big virtual size, we reject it. And for anything else we then tell it
> (with __fill_var) how big the actually available space is.
>
> What I'm wondering now is whether too small x/yres won't lead to problems
> of some sorts ... For multi-screen we set the virtual size to be big
> enough for all crtc, and then just set x/yres to be the smallest output.
> That way fbcon knows to only draw as much as is visible on all screens.
> But if you then pan that too much, the bigger screens might not have a big
> enough buffer anymore and things fail (but shouldn't).
>
> Not sure how to fix that tbh.
Would this be a problem in practice?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2023-04-05 16:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
2023-04-04 19:40 ` Daniel Vetter
2023-04-04 19:40 ` Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
2023-04-04 19:40 ` Daniel Vetter
2023-04-05 10:23 ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 10:23 ` Javier Martinez Canillas
2023-04-04 19:40 ` [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var Daniel Vetter
2023-04-04 19:40 ` Daniel Vetter
2023-04-05 10:52 ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 10:52 ` Javier Martinez Canillas
2023-04-05 13:23 ` [Intel-gfx] " Daniel Vetter
2023-04-05 13:23 ` Daniel Vetter
2023-04-05 16:27 ` Javier Martinez Canillas [this message]
2023-04-05 16:27 ` Javier Martinez Canillas
2023-04-05 17:20 ` [Intel-gfx] " Daniel Vetter
2023-04-05 17:20 ` Daniel Vetter
2023-04-05 17:42 ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 17:42 ` Javier Martinez Canillas
2023-04-05 20:44 ` [Intel-gfx] " Daniel Vetter
2023-04-05 20:44 ` Daniel Vetter
2023-04-05 21:09 ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 21:09 ` Javier Martinez Canillas
2023-04-04 22:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Patchwork
2023-04-04 22:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-05 8:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-05 10:21 ` [Intel-gfx] [PATCH 1/3] " Javier Martinez Canillas
2023-04-05 10:21 ` Javier Martinez Canillas
2023-04-05 10:21 ` Javier Martinez Canillas
2023-04-05 13:25 ` [Intel-gfx] " Daniel Vetter
2023-04-05 13:25 ` Daniel Vetter
2023-04-05 13:25 ` Daniel Vetter
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=87ilea9twa.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tzimmermann@suse.de \
/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.