Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2920397pxb; Tue, 24 Aug 2021 10:37:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdt2lksuFnImO2h7lpkPlAFvSl3TN1WMaE6JJfp/PLLN+be5aao50xmSUyuKo3dY0y0g9K X-Received: by 2002:a92:d1c6:: with SMTP id u6mr27249851ilg.263.1629826651204; Tue, 24 Aug 2021 10:37:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629826651; cv=none; d=google.com; s=arc-20160816; b=aflS+hE42srTryAhVnLSeO/kKd25E0MOtitRr+NX/QVcqQOHjEycMXmkqNuA7tSfOu Jjd4OgDouD8XptqQJTegFDqnLsB/sU+SIrvEMq+r+9PYqlAcBYJTMxcy7v5mn7Ip6Nh9 tZvwLnK6oDjiacASRqdMDtg7yfQraDX5Kp77+el56Ugf7QGFVAe4BEBCI6mAo5A6cThG 7qRKlkd/4gWA+mpegY5CH1VDgZhpdhSBPZ2stlg2AbI4hYUIwa6T+84jSBPXB/QosbeM XxwDhCVFFKoBgyD3QDlSManyOVMEiFUjuhU1chiOmshdugwXf2gx+Dl8zA7/MxcnIs8D lMWw== 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=uFKURimoeN/rcA5YyALcXRaNuO5JXp3gtQmfyKn0rxU=; b=nBSyU3E/PlW0nU62TmqhZFmh3dEVlWtRd52buIbl8Fj1NL44/eEFRloAecYwRPECmn hhST94sNl/CB9YreQDdA1u5v7xCK/g7ZxMmG3GwB5JmU/RCW3zqbbLL9ySSVfdA+NRfP WVQUuHF3NIb7KpBiUpQDCE21Rua3aO51dVcTdXktkDMHi1vL0m2NdopkMIvF3KYVv2gS 4MXg6axAlTq3u0knQfifuv4Z3A1lBwAV4jIG0416TGJQOc4FxZv89TE0eGsXhNv5QJ1o WK74rj26pc5AKHBht4Jva0HWRhpV+lzRxSM1JWbk8PQf5sBZS0W3Req4EiJTwbqIGaWO dVig== 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 y5si17177096ion.91.2021.08.24.10.37.18; Tue, 24 Aug 2021 10:37:31 -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 S241288AbhHXRgL (ORCPT + 99 others); Tue, 24 Aug 2021 13:36:11 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:36500 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240134AbhHXRcK (ORCPT ); Tue, 24 Aug 2021 13:32:10 -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 109241F41A29; Tue, 24 Aug 2021 18:31:21 +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 Subject: [PATCH v2 4/4] drm/panfrost: Handle non-aligned lock addresses Date: Tue, 24 Aug 2021 13:30:28 -0400 Message-Id: <20210824173028.7528-5-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 When locking memory, the base address is rounded down to the nearest page. The current code does not adjust the size in this case, truncating the lock region: Input: [----size----] Round: [----size----] To fix the truncation, extend the lock region by the amount rounded off. Input: [----size----] Round: [-------size------] This bug is difficult to hit under current assumptions: since the size of the lock region is stored as a ceil(log2), the truncation must cause us to cross a power-of-two boundary. This is possible, for example if the caller tries to lock 65535 bytes starting at iova 0xCAFE0010. The existing code rounds down the iova to 0xCAFE0000 and rounds up the lock region to 65536 bytes, locking until 0xCAFF0000. This fails to lock the last 15 bytes. In practice, the current callers pass PAGE_SIZE aligned inputs, avoiding the bug. Therefore this doesn't need to be backported. Still, that's a happy accident and not a precondition of lock_region, so we let's do the right thing to future proof. Signed-off-by: Alyssa Rosenzweig Reported-by: Steven Price --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c index dfe5f1d29763..14be32497ec3 100644 --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -63,6 +63,9 @@ static void lock_region(struct panfrost_device *pfdev, u32 as_nr, u8 region_width; u64 region = iova & PAGE_MASK; + /* After rounding the address down, extend the size to lock the end. */ + size += (region - iova); + /* The size is encoded as ceil(log2) minus(1), which may be calculated * with fls. The size must be clamped to hardware bounds. */ -- 2.30.2