Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2921060pxb; Tue, 24 Aug 2021 10:38:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBdUi97vNUF4Avd5OQvLm3utsbVWTjIEdwBneQmB6krW9QkZFbQMHg3Ty7LnV3YvdxY4hG X-Received: by 2002:a02:cb45:: with SMTP id k5mr34926823jap.112.1629826702838; Tue, 24 Aug 2021 10:38:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629826702; cv=none; d=google.com; s=arc-20160816; b=LibQlnWYL6zzhypoGFx8SQs3SSXAmn3BexSXeWae7ltkwUwDLmAdMI76Z3PXyA51LC DOteadb0dPY50IhjNpgzoVnrawR96Ir7le/ZPBkB4SYVdMQJerFJLIhSTvpINlFLaOGl XhQWCETFaT6hQ+6+d01TJv72dGu7OP+7YWmkh/9+fIQ2o8rIWg8GJTQru613qW0SpoBq 9N9idEP3i3AmWz2wHzcZQhJCe86JHVSR1bYR6SRiTId2FxBKjLXJs2HlsqCmJ9n7d6PX XgLVpIyBltKJbTwvbhFxgBAidOYyTEnZvEYlUd1BJru1fsIkTvsHNffOXJp/i30wJE7t pBAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=UFjB8CHuP6sMYMcmxCKS6vM1cJbq7SB4xI8xnOnDDBE=; b=KpBdo9LfK0sN5+QXwTV7Amzyl/ZClbUm3sEt4L3aDWOunoVuPH6Ur6KpIYhJ3JQ//B aVomviZdnK+bogx2JEIchpAAH4bRiRRIevAFtWsymQO1y/BsarcCbme/kt6P28Zk7LGR FbNUr4YxKU0qTZ8h2dVS8Sp7aH+GJ3xTw2sAEbP3511gL+v1ZpeA0f7CHq9kgTdz5Q5g mvROgDDZvHN9UlliOn8cs0sB1apJm4Ah1hHLixKP4SNdik8f8NvaIa5AAItBn4gQj5Mb /k+9WC+gOXCFKs9qJh9TqCeWLtbFdNZXVDj5w87IsIfleOAiaIEdNxDyd7yqtOira5/l GZgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r19si12520242jad.121.2021.08.24.10.38.11; Tue, 24 Aug 2021 10:38:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241211AbhHXRhB (ORCPT + 99 others); Tue, 24 Aug 2021 13:37:01 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:36446 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240128AbhHXRbh (ORCPT ); Tue, 24 Aug 2021 13:31:37 -0400 Received: from localhost.localdomain (unknown [IPv6:2600:8800:8c06:1000::c8f3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alyssa) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id D98E21F4270E; Tue, 24 Aug 2021 18:30:48 +0100 (BST) From: Alyssa Rosenzweig To: dri-devel@lists.freedesktop.org Cc: Rob Herring , Tomeu Vizoso , Steven Price , Alyssa Rosenzweig , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan , stable@vger.kernel.org Subject: [PATCH v2 1/4] drm/panfrost: Simplify lock_region calculation Date: Tue, 24 Aug 2021 13:30:25 -0400 Message-Id: <20210824173028.7528-2-alyssa.rosenzweig@collabora.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210824173028.7528-1-alyssa.rosenzweig@collabora.com> References: <20210824173028.7528-1-alyssa.rosenzweig@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In lock_region, simplify the calculation of the region_width parameter. This field is the size, but encoded as ceil(log2(size)) - 1. ceil(log2(size)) may be computed directly as fls(size - 1). However, we want to use the 64-bit versions as the amount to lock can exceed 32-bits. This avoids undefined (and completely wrong) behaviour when locking all memory (size ~0). In this case, the old code would "round up" ~0 to the nearest page, overflowing to 0. Since fls(0) == 0, this would calculate a region width of 10 + 0 = 10. But then the code would shift by (region_width - 11) = -1. As shifting by a negative number is undefined, UBSAN flags the bug. Of course, even if it were defined the behaviour is wrong, instead of locking all memory almost none would get locked. The new form of the calculation corrects this special case and avoids the undefined behaviour. Signed-off-by: Alyssa Rosenzweig Reported-and-tested-by: Chris Morgan Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c index 0da5b3100ab1..f6e02d0392f4 100644 --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -62,21 +62,12 @@ static void lock_region(struct panfrost_device *pfdev, u32 as_nr, { u8 region_width; u64 region = iova & PAGE_MASK; - /* - * fls returns: - * 1 .. 32 - * - * 10 + fls(num_pages) - * results in the range (11 .. 42) - */ - - size = round_up(size, PAGE_SIZE); - region_width = 10 + fls(size >> PAGE_SHIFT); - if ((size >> PAGE_SHIFT) != (1ul << (region_width - 11))) { - /* not pow2, so must go up to the next pow2 */ - region_width += 1; - } + /* The size is encoded as ceil(log2) minus(1), which may be calculated + * with fls. The size must be clamped to hardware bounds. + */ + size = max_t(u64, size, PAGE_SIZE); + region_width = fls64(size - 1) - 1; region |= region_width; /* Lock the region that needs to be updated */ -- 2.30.2