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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 B2A58C4338F for ; Mon, 23 Aug 2021 21:09:22 +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 54B3B61037 for ; Mon, 23 Aug 2021 21:09:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 54B3B61037 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7452389B83; Mon, 23 Aug 2021 21:09:21 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by gabe.freedesktop.org (Postfix) with ESMTPS id 649F289B83 for ; Mon, 23 Aug 2021 21:09:20 +0000 (UTC) Received: from maud (unknown [IPv6:2600:8800:8c06:1000::c8f3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alyssa) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 336701F425BC; Mon, 23 Aug 2021 22:09:14 +0100 (BST) Date: Mon, 23 Aug 2021 17:09:08 -0400 From: Alyssa Rosenzweig To: Steven Price Cc: Alyssa Rosenzweig , dri-devel@lists.freedesktop.org, Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan , stable@vger.kernel.org Subject: Re: [PATCH 1/3] drm/panfrost: Simplify lock_region calculation Message-ID: References: <20210820213117.13050-1-alyssa.rosenzweig@collabora.com> <20210820213117.13050-2-alyssa.rosenzweig@collabora.com> <192e5a1b-2caf-11a8-f090-ec5649ea16b5@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <192e5a1b-2caf-11a8-f090-ec5649ea16b5@arm.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > > 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). Indeed. I've updated the commit message in v2 to explain what goes wrong (your analysis was spot on, but a mailing list message is more ephermal than a commit message). I'll send out v2 tomorrow assuming nobody objects to v1 in the mean time. Thanks for the review. > 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< (iova & mask) != ((iova + size) & mask) then you are potentially failing > to lock the end of the intended region. kbase has added some code to > handle this: > > > /* 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? Oh, I missed this one. Guess we have 4 bugs with this code instead of just 3, yikes. How could such a short function be so deeply and horribly broken? 😃 Should I add a fourth patch to the series to fix this?