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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 684FDC54EBC for ; Tue, 10 Jan 2023 20:30:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C5A4410E493; Tue, 10 Jan 2023 20:30:14 +0000 (UTC) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9EA9310E493 for ; Tue, 10 Jan 2023 20:30:12 +0000 (UTC) Received: by mail-il1-x134.google.com with SMTP id h26so6980843ila.11 for ; Tue, 10 Jan 2023 12:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=w0Ug/ql1k2yCindQKTRR7rZIRzQnKNrHLeSqG8fryRU=; b=lLxUx/bMoyOfuYe2X/8VFsQ+pLZ38ds+Rz4HDvDSmzx62mxYFzBIdYtTKovwsZi9i+ la0f9V3xZrTk6WFUBU8WLFd90V5NdTf63r04MkaXO3bOPatguw9Avrkcmgr7dFcHJh0L s3mA0o5rahMqaSVak4BdlT0j7sTgadkvT1Xu8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=w0Ug/ql1k2yCindQKTRR7rZIRzQnKNrHLeSqG8fryRU=; b=2y5vOs+8oHuUa2mJOSm4JLx0/q7zkiYZLKg05fz5cCK3b+YDvwVfKhE6H1OtjEc4m8 pQGzUHkkms2acXrDXIc81SHqTKivz86UZP2pnyJFXCU8rVlavmI8SSh5ZJ0hYkhhLHAX KeO5IZtwSQ3KBhpfyq21gGVMXG/PpX36QKMK0EHT+Wg5Ujvs4bMKBtI98X2EqSr/AU9g s7e6quEN8s0HMWyFGdjrimGR8sJRCUGHjzPvvXNQOAw31fctA9KEpifOA3gZ14jK9DLS j6Ej415hAarzL1MjKqNYwQ5DWPDNwZUMZjr891Y5VkXLoGB0RtEZ9SkIhuX1WimqHNj8 mjRA== X-Gm-Message-State: AFqh2kpNvmSj4hbswrlF0B8RhXCVtNeK9R59z7l4w7PPTqZz3KfOXNc0 qibb/BH3NX9lvUQCmQtrTWUVXA== X-Google-Smtp-Source: AMrXdXuYEbx64HsIkwIR1X0fW6/MkoxznuZHCX2SRdTFXE879B3OEgvIbygmt0TOAFMmFnqN+0lsCg== X-Received: by 2002:a92:1e08:0:b0:30d:7ce3:448b with SMTP id e8-20020a921e08000000b0030d7ce3448bmr15581670ile.14.1673382611793; Tue, 10 Jan 2023 12:30:11 -0800 (PST) Received: from chromium.org ([2620:15c:183:200:d1f8:2b5e:3e1d:2620]) by smtp.gmail.com with ESMTPSA id t13-20020a92d14d000000b003039a19a927sm3913441ilg.7.2023.01.10.12.30.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Jan 2023 12:30:11 -0800 (PST) Date: Tue, 10 Jan 2023 13:30:09 -0700 From: Drew Davenport To: Juha-Pekka Heikkila Message-ID: References: <20221226225246.1.I15dff7bb5a0e485c862eae61a69096caf12ef29f@changeid> <8b4448d0-d9ea-95a6-83ee-513fe73c793f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b4448d0-d9ea-95a6-83ee-513fe73c793f@gmail.com> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is > 0 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, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , Rodrigo Vivi , Juha-Pekka =?iso-8859-1?Q?Heikkil=E4?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Jan 03, 2023 at 12:42:43PM +0200, Juha-Pekka Heikkila wrote: > Hi Drew, Hi Juha-Pekka, sorry for the late response since I was on vacation. > > this is good find. I went looking where the problem is in and saw what you > probably also saw earlier. > > I was wondering if diff below would be better fix? I assume this would end > up with einval or erange in your case but code flow otherwise would stay as > is while fixing all future callers for same issue: Yes, the function you identify below is where I encountered divide-by-zero errors. If width/height less than 1 is a legitimate use case, then your proposed solution looks like it would be better. It should have no risk of regression in userspace either, which is nice. I tested your patch, and as expected I did not hit the divide-by-zero error, though the test commit was rejected due to a check further along inside skl_update_scaler. Perhaps there is some other configuration which would pass the test commit with a width/height less than 1, but I didn't dig much further. > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > index 10e1fc9d0698..a9948e8d3543 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect > *src, > const struct drm_rect *dst, > unsigned int rate) > { > - unsigned int src_w, src_h, dst_w, dst_h; > + unsigned int src_w, src_h, dst_w, dst_h, dst_wh; > > src_w = drm_rect_width(src) >> 16; > src_h = drm_rect_height(src) >> 16; > @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect > *src, > dst_w = min(src_w, dst_w); > dst_h = min(src_h, dst_h); > > - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), > - dst_w * dst_h); > + /* in case src contained only fractional part */ > + dst_wh = max(dst_w * dst_h, (unsigned) 1); > + > + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh); > } > > unsigned int intel_plane_pixel_rate(const struct intel_crtc_state > *crtc_state, > > > What do you think? I'll in any case come up with some test for this in igt. I see that you've posted your fix to the list already. Adding a test to cover this in IGT also sounds great. Thanks! Breadcrumbs to Juha-Pekka's patch for anyone following this thread: https://patchwork.freedesktop.org/series/112396/ > > /Juha-Pekka > > On 27.12.2022 7.53, Drew Davenport wrote: > > The error message suggests that the height of the src rect must be at > > least 1. Reject source with height of 0. > > > > Signed-off-by: Drew Davenport > > > > --- > > I was investigating some divide-by-zero crash reports on ChromeOS which > > pointed to the intel_adjusted_rate function. Further prodding showed > > that I could reproduce this in a simple test program if I made src_h > > some value less than 1 but greater than 0. > > > > This seemed to be a sensible place to check that the source height is at > > least 1. I tried to repro this issue on an amd device I had on hand, and > > the configuration was rejected. > > > > Would it make sense to add a check that source dimensions are at least 1 > > somewhere in core, like in drm_atomic_plane_check? Or is that a valid > > use case on some devices, and thus any such check should be done on a > > per-driver basis? > > > > Thanks. > > > > drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c > > index 4b79c2d2d6177..9b172a1e90deb 100644 > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > > @@ -1627,7 +1627,7 @@ static int skl_check_main_surface(struct intel_plane_state *plane_state) > > u32 offset; > > int ret; > > - if (w > max_width || w < min_width || h > max_height) { > > + if (w > max_width || w < min_width || h > max_height || h < 1) { > > drm_dbg_kms(&dev_priv->drm, > > "requested Y/RGB source size %dx%d outside limits (min: %dx1 max: %dx%d)\n", > > w, h, min_width, max_width, max_height); >