[PATCH 6/7] drm/crtc: add sanity checks to create_dumb()

David Herrmann dh.herrmann at gmail.com
Tue Jan 21 03:52:36 PST 2014


Hi

On Tue, Jan 21, 2014 at 12:42 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Tue, Jan 21, 2014 at 12:17:35PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Tue, Jan 21, 2014 at 10:49 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > On Mon, Jan 20, 2014 at 08:26:28PM +0100, David Herrmann wrote:
>> >> Lets make sure some basic expressions are always true:
>> >>   bpp != NULL
>> >>   width != NULL
>> >>   height != NULL
>> >>   stride = bpp * width < 2^32
>> >>   size = stride * height < 2^32
>> >>   PAGE_ALIGN(size) < 2^32
>> >>
>> >> At least the udl driver doesn't check for multiplication-overflows, so
>> >> lets just make sure it will never happen. These checks allow drivers to do
>> >> any 32bit math without having to test for mult-overflows themselves.
>> >>
>> >> The two divisions might hurt performance a bit, but dumb_create() is only
>> >> used for scanout-buffers, so that should be fine. We could use 64bit math
>> >> to avoid the divisions, but that may be slow on 32bit machines.. Or maybe
>> >> there should just be a "safe_mult32()" helper, which currently doesn't
>> >> exist (I think?).
>> >>
>> >> Signed-off-by: David Herrmann <dh.herrmann at gmail.com>
>> >> ---
>> >>  drivers/gpu/drm/drm_crtc.c | 15 +++++++++++++++
>> >>  1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> index 266a01d..ff647fa 100644
>> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> @@ -3738,9 +3738,24 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>> >>                              void *data, struct drm_file *file_priv)
>> >>  {
>> >>       struct drm_mode_create_dumb *args = data;
>> >> +     u32 Bpp, stride, size;
>> >
>> > s/Bpp/bpp/
>>
>> It's actually "Bytes per pixel", not "Bits per pixel". We generally
>> use "bpp" as "bits per pixel" so I'd like to avoid the confusion. But
>> yeah, upper-case names are unusual so I can also use bytes_pp or sth
>> similar?
>
> cpp is fairly commonly used for bytes per pixel, if you want to stick to
> something short but still recognizable.

Because "c" comes after "b"? Or is there any other logic here? But
sounds good, will send a v2 shortly.

Thanks
David


More information about the dri-devel mailing list