Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5367894yba; Mon, 13 May 2019 09:39:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqz5VK+bClQHON+gSElmRfwavYsTFXXKN3y8bQLkX9ruPHvSRXKXFe54A/Xab24dweIq7uob X-Received: by 2002:a17:902:b695:: with SMTP id c21mr32602441pls.160.1557765583619; Mon, 13 May 2019 09:39:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557765583; cv=none; d=google.com; s=arc-20160816; b=hm68q0kAIOcHo8ZcgR06O6+LXnS2jqyXMDF7Z0drI4grFhAy7Qq7d/ULDU+5ukz+hq jmyMno6+Cl02bHGojgW8hqyUMmHjiUrcFsFaNFIBcAkkZw5PBQbVa0RU6KoxJib1IKGE p72oPyjzP4J5Xfd44dCTFDYpXfjfeSO4UoU9Nu9lon/WQVNYGJfPk8U3wQ9kkt71FMlZ Qr0OwuTXxZgL6go88PbHCJKfSBPKgpbPJweg5i9Z9gpJYfTNxAEh/RydUQXGvCJcV8jk Ap3SaMHXs/zHwjha+Olz6ai4N2F1A2khajb9dXjShHedGoVMP4PIMm0l8ZAY8/sTjbDb IRaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=BNGB6lS9iyvD945o0tLb+endV+e8eX6ZRVLY8HAidtY=; b=nM9bR0Mqhnuchek79gneZ0euU42eEk4Z5C1JZyhl7v0P9P7PuO3pRIDaiHh4koyN7o 7edDTXYBO05gvN2SkBVCVZq3IkfUAxIerJhGVp/d/JsOrJVFbflrd0+KzEI6ph/XrAvN 8p2SQb0zDfSRyLKRUF3BG3ZfiD/b7B7GAj02ClmDoyKeLve4PV+D6ugKTZB6IUe4T1Kg ZPEDlgVE/I2TPhbodIu1FJHTcj+G8Ow1HYNY0tJuFnUJa4h+7VgEGingXQR7yVhfrgZA aynfHbrrgMqG0tDJJUjWMjSrTMcvbIDiMQ2/kHslPDmzLnluXjCWBgfmeqgO7iPvTdmy +P5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si15795967pgs.86.2019.05.13.09.39.26; Mon, 13 May 2019 09:39:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731140AbfEMPOF (ORCPT + 99 others); Mon, 13 May 2019 11:14:05 -0400 Received: from foss.arm.com ([217.140.101.70]:59052 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726738AbfEMPOF (ORCPT ); Mon, 13 May 2019 11:14:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9B5C7341; Mon, 13 May 2019 08:14:04 -0700 (PDT) Received: from [10.1.196.69] (e112269-lin.cambridge.arm.com [10.1.196.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 655D03F71E; Mon, 13 May 2019 08:14:03 -0700 (PDT) Subject: Re: [PATCH] drm/panfrost: Use drm_gem_dump_map_offset() To: Chris Wilson , Daniel Vetter Cc: David Airlie , Alyssa Rosenzweig , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Tomeu Vizoso References: <20190513143244.16478-1-steven.price@arm.com> <20190513143921.GP17751@phenom.ffwll.local> <155775884217.2165.11223399053598674062@skylake-alporthouse-com> From: Steven Price Message-ID: <0b7f0b7f-3e14-f5bb-368a-08037c2a8529@arm.com> Date: Mon, 13 May 2019 16:14:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155775884217.2165.11223399053598674062@skylake-alporthouse-com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/05/2019 15:47, Chris Wilson wrote: > Quoting Daniel Vetter (2019-05-13 15:39:21) >> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote: >>> panfrost_ioctl_mmap_bo() contains a reimplementation of >>> drm_gem_dump_map_offset() but with a bug - it allows mapping imported >>> objects (without going through the exporter). Fix this by switching to >>> use the generic drm_gem_dump_map_offset() function instead which has the >>> bonus of simplifying the code. >> >> gem_dumb stuff is for kms drivers, panfrost is a render driver. We're >> generally trying to separate these two worlds somewhat cleanly. >> >> I think it'd be good to have a non-dumb version of this in the core, and >> use that. Or upgrade the dumb version to be that helper for everyone (and >> drop the _dumb). I'm slightly confused by what you think is the best course of action here. I can create a patch dropping the '_dumb' from drm_gem_dump_map_offset() if that's the objection. Or do you want a helper function with two callers (the 'dump' and the 'shmem' versions)? > More specifically, since panfrost is using the drm_gem_shmem helper and > vm_ops, it too can provide the wrapper as it is the drm_gem_shmem layer > that implies that trying to mmap an imported object is an issue as that > is not a universal problem. mmap'ing an imported object isn't a problem as such. But rather than going behind the exporter's back we would need to call dma_buf_mmap() to ensure that the exporter can do whatever is necessary. I could add a wrapper in drm_gem_shmem_helper, but I'm not sure what the benefit of a wrapper here is? Steve