From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C799AC33CB6 for ; Thu, 23 Jan 2020 13:58:43 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A685D20684 for ; Thu, 23 Jan 2020 13:58:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A685D20684 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3C4166FBEE; Thu, 23 Jan 2020 13:58:43 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0BA076FBEE for ; Thu, 23 Jan 2020 13:58:42 +0000 (UTC) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 05:58:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,354,1574150400"; d="scan'208";a="288314808" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 23 Jan 2020 05:58:39 -0800 Received: by stinkbox (sSMTP sendmail emulation); Thu, 23 Jan 2020 15:58:38 +0200 Date: Thu, 23 Jan 2020 15:58:38 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Chris Wilson Message-ID: <20200123135838.GQ13686@intel.com> References: <20200123125934.1401755-1-chris@chris-wilson.co.uk> <20200123132707.GK13686@intel.com> <157978674377.19995.13523461350756168685@skylake-alporthouse-com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <157978674377.19995.13523461350756168685@skylake-alporthouse-com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Detect overflow in calculating dumb buffer size X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Jan 23, 2020 at 01:39:03PM +0000, Chris Wilson wrote: > Quoting Ville Syrj=E4l=E4 (2020-01-23 13:27:07) > > On Thu, Jan 23, 2020 at 12:59:34PM +0000, Chris Wilson wrote: > > > To multiply 2 u32 numbers to generate a u64 in C requires a bit of > > > forewarning for the compiler. > > > = > > > Signed-off-by: Chris Wilson > > > Cc: Ramalingam C > > > Cc: Joonas Lahtinen > > > Cc: stable@vger.kernel.org > > > --- > > > drivers/gpu/drm/i915/i915_gem.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > = > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i= 915_gem.c > > > index 0a20083321a3..ff79da5657f8 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -265,7 +265,10 @@ i915_gem_dumb_create(struct drm_file *file, > > > DRM_FORMAT_MOD_LINE= AR)) > > > args->pitch =3D ALIGN(args->pitch, 4096); > > > = > > > - args->size =3D args->pitch * args->height; > > > + if (args->pitch < args->width) > > > + return -EINVAL; > > > + > > > + args->size =3D mul_u32_u32(args->pitch, args->height); > > = > > I thought something would have checked these against the mode_config > > fb limits already. But can't see code like that anywhere. Maybe we > > should just do that in the core? > = > While it is in uapi/drm_mode.h, is there any restriction that the dumb > buffer has to be used with a framebuffer? Not that I have a good use > case, just wondering if we need to be so proscriptive. I think the general concensus has been that anything else is an abuse of the interface (not that it has stopped people from doing it IIRC). But maybe there's some good use for it that I can't think up. Reviewed-by: Ville Syrj=E4l=E4 > = > We create something that is compatible but presume we will need later > validation against HW. > -Chris -- = Ville Syrj=E4l=E4 Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D89FC2D0DB for ; Thu, 23 Jan 2020 13:58:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 18D9A20684 for ; Thu, 23 Jan 2020 13:58:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726771AbgAWN6m (ORCPT ); Thu, 23 Jan 2020 08:58:42 -0500 Received: from mga03.intel.com ([134.134.136.65]:17700 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726729AbgAWN6m (ORCPT ); Thu, 23 Jan 2020 08:58:42 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 05:58:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,354,1574150400"; d="scan'208";a="288314808" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 23 Jan 2020 05:58:39 -0800 Received: by stinkbox (sSMTP sendmail emulation); Thu, 23 Jan 2020 15:58:38 +0200 Date: Thu, 23 Jan 2020 15:58:38 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Detect overflow in calculating dumb buffer size Message-ID: <20200123135838.GQ13686@intel.com> References: <20200123125934.1401755-1-chris@chris-wilson.co.uk> <20200123132707.GK13686@intel.com> <157978674377.19995.13523461350756168685@skylake-alporthouse-com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <157978674377.19995.13523461350756168685@skylake-alporthouse-com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Jan 23, 2020 at 01:39:03PM +0000, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-01-23 13:27:07) > > On Thu, Jan 23, 2020 at 12:59:34PM +0000, Chris Wilson wrote: > > > To multiply 2 u32 numbers to generate a u64 in C requires a bit of > > > forewarning for the compiler. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Ramalingam C > > > Cc: Joonas Lahtinen > > > Cc: stable@vger.kernel.org > > > --- > > > drivers/gpu/drm/i915/i915_gem.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > > index 0a20083321a3..ff79da5657f8 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -265,7 +265,10 @@ i915_gem_dumb_create(struct drm_file *file, > > > DRM_FORMAT_MOD_LINEAR)) > > > args->pitch = ALIGN(args->pitch, 4096); > > > > > > - args->size = args->pitch * args->height; > > > + if (args->pitch < args->width) > > > + return -EINVAL; > > > + > > > + args->size = mul_u32_u32(args->pitch, args->height); > > > > I thought something would have checked these against the mode_config > > fb limits already. But can't see code like that anywhere. Maybe we > > should just do that in the core? > > While it is in uapi/drm_mode.h, is there any restriction that the dumb > buffer has to be used with a framebuffer? Not that I have a good use > case, just wondering if we need to be so proscriptive. I think the general concensus has been that anything else is an abuse of the interface (not that it has stopped people from doing it IIRC). But maybe there's some good use for it that I can't think up. Reviewed-by: Ville Syrjälä > > We create something that is compatible but presume we will need later > validation against HW. > -Chris -- Ville Syrjälä Intel