Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp317425pxb; Fri, 8 Jan 2021 05:58:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJwBpHQtx7Y7/zuF01OqFFX3ADcRHdaHsKfV1wxIvVS4XavM7MfPMFlgJCf9nCq1isCEVyLj X-Received: by 2002:a17:906:1796:: with SMTP id t22mr2615236eje.372.1610114320096; Fri, 08 Jan 2021 05:58:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610114320; cv=none; d=google.com; s=arc-20160816; b=Uw6SIWyr5ShRRq7jnGR5zwhxMx5MKiKEoXR4/a1IOsHmfF0KKmamltwzD+2YA9Edyb NSieMyeNvGJ2Km2JrkvvpUzKWM9+dQdKwPmeuGffgA8wc1xIJfnpFAbo9MccCwbjlEJn XMqSE0kOrfFHSFniYKTUGUlNo04Lju8PlgKcTc83UiCNd2eWNeuuaczW1Tbcb9FVNHMF LgJWRmfalFfP0y/+umUJMbwqDzEzNu01s1JaKiHD06823zP7Hhnpzmd6cT8zwHmS72x0 2NI3EBH/FaS/6Znj8ekpHMWrt1Mqlf/P0VQw7lu0q3NbADE5rXtUxvn3IMYFi408zzvj 7PLQ== 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:dkim-signature; bh=Q91uhwFRfmIKcWPttNsrBoB66RrXUH9oGtyQnvttSXI=; b=utPacd4QsaekV1Z93KIUlH+39vAjW777eMxMTRtr/zznvhYI5jEBuPbbYWiul1gvHg /Q45o1lRr6MF8vjJnXX3ocMNuEIKaU3vYQ8D8ZDOtuEIuBqXgTZnw1spYDkXWRvKPpdm sNeGhkJN11LlkQh51qmKOCI6Ngr1ynSxPZ3k+wif4XYWjidJ3RjjibrR88iyPIvofPyc VGcuwqkYKnBPc+kVFgqUhxN1fZwLxFUnjZwIn4eX+B+V93khDRcUgg9NPuxn0oEQ4tuH JjXMPywrxwuXbBud0g8ln/u5tEM+rrPXMYjTNRfL/OUYloqpvNkWuIUzhdWv3qO56Meb Caag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DQXxUVb6; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bw26si3565566ejb.644.2021.01.08.05.58.16; Fri, 08 Jan 2021 05:58:40 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DQXxUVb6; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726943AbhAHN5V (ORCPT + 99 others); Fri, 8 Jan 2021 08:57:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbhAHN5U (ORCPT ); Fri, 8 Jan 2021 08:57:20 -0500 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 181E7C0612F4; Fri, 8 Jan 2021 05:56:40 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id m5so9077772wrx.9; Fri, 08 Jan 2021 05:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q91uhwFRfmIKcWPttNsrBoB66RrXUH9oGtyQnvttSXI=; b=DQXxUVb6TciWFgP7OcgXU45ci44YnDtH3mBxAimjk67e+oonwcPLS3fiWqg2MX48TZ c7TTeAzKDudMuKa3R6Flqfdmsi6qyMd0TJsq4RJ4i0E+tgLxRAlz/WiW9wo/RfcqnW/R 3sYx7mAWg34mTpqM62WXbEipKhnqNlzV/QEq1QIiMHuTqV+R0GWcV04OGlyDzCb0yXKH Rdp8aGDCKwBpgfZHx2Y3/uOYwE6WSUpQXM+Mt3aXpQ8EjetfkfkfVlZFTcwzG6YilRzU lzgW5KF2Vqk6OEQOSn51UUYldBKmXcBdFrywOjIGc94/yA47Zl0VIzwRDJMiG4HEy9O1 +qRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q91uhwFRfmIKcWPttNsrBoB66RrXUH9oGtyQnvttSXI=; b=Yk6M3Zlm9qDpiWmljFc7r+iPsu1LnC5ojShjewJh2ZKLscHTBvSgZtUG2lzq/w41Rn rgY5BWXBAjW+/sOpJSjtzBOzAj7DgDERGc+NAx7buhF4FgX8YT9BgfP2MaE+mdI8Qijo 2DyX8un2dVQs5VCP0djuCm/u1Ttxm9NRdBSqT0sO2lNrk+ZAAwzlha7dbY+mg4EPCnqy cKIZ7HsKTmY4pgDVYmBkrlHimL3ICg/GVHj29lUxF2sBIpkjzGUwRbm4ICD2Wct7liBb R95FRjPEBDo8eEaLOUyvmdllEcDyoyccD9QeIhwEUZL/n0K24k8jWod6nUuByfnCNhiu WrUw== X-Gm-Message-State: AOAM533WVwDwig8OiQWaKlIEH43ttIwCsJEuy0KNUKGJRWv5hZ4B1SHN cg/NzyuQUPOSFOZy8TZRD3VnVQGEOwXOGIR/ X-Received: by 2002:adf:df06:: with SMTP id y6mr3804923wrl.241.1610114198890; Fri, 08 Jan 2021 05:56:38 -0800 (PST) Received: from [192.168.74.106] (178-169-161-196.razgrad.ddns.bulsat.com. [178.169.161.196]) by smtp.gmail.com with ESMTPSA id o124sm12646637wmb.5.2021.01.08.05.56.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jan 2021 05:56:37 -0800 (PST) Subject: Re: [PATCH] drm/msm: Fix MSM_INFO_GET_IOVA with carveout To: Rob Clark Cc: ~postmarketos/upstreaming@lists.sr.ht, Sean Paul , David Airlie , Daniel Vetter , Bjorn Andersson , Jordan Crouse , linux-arm-msm , dri-devel , freedreno , Linux Kernel Mailing List References: <20210102202437.1630365-1-iskren.chernev@gmail.com> From: Iskren Chernev Message-ID: Date: Fri, 8 Jan 2021 15:56:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/8/21 12:36 AM, Rob Clark wrote: > On Thu, Jan 7, 2021 at 9:20 AM Rob Clark wrote: >> >> On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev wrote: >>> >>> The msm_gem_get_iova should be guarded with gpu != NULL and not aspace >>> != NULL, because aspace is NULL when using vram carveout. >>> >>> Fixes: 933415e24bd0d ("drm/msm: Add support for private address space instances") >>> >>> Signed-off-by: Iskren Chernev >>> --- >>> drivers/gpu/drm/msm/msm_drv.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c >>> index c5e61cb3356df..c1953fb079133 100644 >>> --- a/drivers/gpu/drm/msm/msm_drv.c >>> +++ b/drivers/gpu/drm/msm/msm_drv.c >>> @@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device *dev, >>> struct drm_file *file, struct drm_gem_object *obj, >>> uint64_t *iova) >>> { >>> + struct msm_drm_private *priv = dev->dev_private; >>> struct msm_file_private *ctx = file->driver_priv; >>> >>> - if (!ctx->aspace) >>> + if (!priv->gpu) >>> return -EINVAL; >> >> Does this actually work? It seems like you would hit a null ptr deref >> in msm_gem_init_vma().. and in general I think a lot of code paths >> would be surprised by a null address space, so this seems like a risky >> idea. > > oh, actually, I suppose it is ok, since in the vram carveout case we > create the vma up front when the gem obj is created.. > > (still, it does seem a bit fragile.. and easy for folks testing on > devices not using vram carvout to break.. hmm..) In _msm_gem_new add_vma is called with NULL, so consequently lookup_vma finds it when aspace is NULL. Also, this is how the code was before the "breaking" change, so it should not be worse. I'll be happy to work on refactoring this a bit, but some some documentation about the different gpu/mdp pieces and how they fit together won't hurt. Regards, Iskren > BR, > -R > >> Maybe instead we should be creating an address space for the vram carveout? >> >> BR, >> -R >> >> >>> /* >>> -- >>> 2.29.2 >>>