Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1708647pxb; Mon, 23 Aug 2021 02:41:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtfGqyq/8OjzMklVOI42SZamE16Fm56bTCeZX3OWm49Cf/IYBrS7G76gdNj5Us6EMWNX6Q X-Received: by 2002:a05:6638:29a:: with SMTP id c26mr28706180jaq.58.1629711707092; Mon, 23 Aug 2021 02:41:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629711707; cv=none; d=google.com; s=arc-20160816; b=1J4YNlQC/RZY9I9THV4Bvhqq3U6LJ8dFYqyIdKoxHoOokW+SJPQ74stiBmWJq694gH h2P6D0Yze6do7KUxoNu0KircreR9O5q6ZPFRSE1W2svMBdz1GtCuE6x5AnZLR6QB5kMC D+YPNSICISIfSxJAxvGj4Qt4ja9zyo4Ao2J0nk2Iu/2q/iXlaXauutHpOIR2NAJerBA9 dGBsH0djffM8nUbqRu/FQc7BmVnVeUKZDwsqBUj/C3A4n9dgLNJ2AZV/VBN/bQtjzNjz 97dGNBGh9ra270Nwpub1y78vSTAm5rJSwlHeTNoB3nZWfy7f57SI+zrEPOFfEe0WXgz5 8omw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=SbZ+mUObmAMBnytOJxNs73cSc3L0xhTkyNWTsocyHmM=; b=jHyVt+8K09tUZaKh94qx0sWmcVQkN1f4cghe9h962W1RnjID9edwbrryNY2h9kJiP1 0dqofTzimBeUJcDrcmevXTf93fyBkiXxxvqW1a8PCc50DLVgwXQ8AAsq/9JZ0STIb7kl ODgzwtCCQ5E0II5y5FmpbCjY6WhpYe9mZxUP97vM4bTBWkkxxdTPgmFXP/8noN5lS8ZW D5R7ILtctfm9MgVfBSxVvGcCqTzPcMXR1jvJ+dAfKemwX22BmKT9JtoPUjLJ147J4uNT Z+nBsoBwuBPcyiuFWDeiDYZMk/1FzbRwIKoGaT6LBrwqTk/vZ1HEg0GEbXNr9OVte8qQ GvzQ== 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=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p4si14494931ilq.160.2021.08.23.02.41.36; Mon, 23 Aug 2021 02:41:47 -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=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232203AbhHWJla (ORCPT + 99 others); Mon, 23 Aug 2021 05:41:30 -0400 Received: from foss.arm.com ([217.140.110.172]:50536 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229845AbhHWJla (ORCPT ); Mon, 23 Aug 2021 05:41:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 84B136D; Mon, 23 Aug 2021 02:40:47 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 396053F66F; Mon, 23 Aug 2021 02:40:46 -0700 (PDT) Subject: Re: [PATCH 1/3] drm/panfrost: Simplify lock_region calculation To: Alyssa Rosenzweig , dri-devel@lists.freedesktop.org Cc: Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan , stable@vger.kernel.org References: <20210820213117.13050-1-alyssa.rosenzweig@collabora.com> <20210820213117.13050-2-alyssa.rosenzweig@collabora.com> From: Steven Price Message-ID: <192e5a1b-2caf-11a8-f090-ec5649ea16b5@arm.com> Date: Mon, 23 Aug 2021 10:40:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210820213117.13050-2-alyssa.rosenzweig@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/08/2021 22:31, Alyssa Rosenzweig wrote: > In lock_region, simplify the calculation of the region_width parameter. > This field is the size, but encoded as log2(ceil(size)) - 1. > log2(ceil(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 behaviour when locking all memory (size ~0), > caught by UBSAN. It might have been useful to mention what it is that UBSAN specifically picked up (it took me a while to spot) - but anyway I think there's a bigger issue with it being completely wrong when size == ~0 (see below). > Signed-off-by: Alyssa Rosenzweig > Reported-and-tested-by: Chris Morgan > Cc: However, I've confirmed this returns the same values and is certainly more simple, so: Reviewed-by: Steven Price > --- > 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); This seems to be the first issue - ~0 will be 'rounded up' to 0. > > - region_width = 10 + fls(size >> PAGE_SHIFT); fls(0) == 0, so region_width == 10. > - if ((size >> PAGE_SHIFT) != (1ul << (region_width - 11))) { Presumably here's where UBSAN objects - we're shifting by a negative value, which even it it happens to works means the lock region is tiny and certainly not what was intended! It might well be worth a: Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Note for anyone following along at (working-from-) home: although this code was cargo culted from kbase - kbase is fine because it takes a pfn and doesn't do the round_up() stage. Which also exposes the second bug (fixed in patch 2): a size_t isn't big enough on 32 bit platforms (all Midgard/Bifrost GPUs have a VA size bigger than 32 bits). Again kbase gets away with a u32 because it's a pfn. There is potentially a third bug which kbase only recently attempted to fix. The lock address is effectively rounded down by the hardware (the bottom bits are ignored). So if you have mask=(1< /* Round up if some memory pages spill into the next region. */ > region_frame_number_start = pfn >> (lockaddr_size_log2 - PAGE_SHIFT); > region_frame_number_end = > (pfn + num_pages - 1) >> (lockaddr_size_log2 - PAGE_SHIFT); > > if (region_frame_number_start < region_frame_number_end) > lockaddr_size_log2 += 1; I guess we should too? Steve > - /* 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 */ >