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

[Chris Wilson]

On Tue, Jan 21, 2014 at 12:52:36PM +0100, David Herrmann wrote:
> 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.

chars (octets) per pixel.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre