Received-SPF: pass (google.com: domain of linux-kernel+bounces-211732-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 12 Jun 2024 17:00:45 +0200
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Peng Fan <peng.fan@nxp.com>, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
Message-ID: <Zmm4HSkia-x_oRWR@phenom.ffwll.local>
Mail-Followup-To: Thomas Zimmermann <tzimmermann@suse.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Peng Fan <peng.fan@nxp.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <20240604080328.4024838-1-peng.fan@oss.nxp.com>
 <8f4a6d80-dd3e-422f-88af-d26f50c973ff@suse.de>
 <e307fdc0-553d-4946-9017-ed3a28e9cae2@suse.de>
 <87cyomsiqt.fsf@minerva.mail-host-address-is-not-set>
 <14a7c534-af3f-43b8-a24c-501a9af97936@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <14a7c534-af3f-43b8-a24c-501a9af97936@suse.de>

On Wed, Jun 12, 2024 at 10:37:14AM +0200, Thomas Zimmermann wrote:
> Hi Javier
> 
> Am 12.06.24 um 09:49 schrieb Javier Martinez Canillas:
> > Thomas Zimmermann <tzimmermann@suse.de> writes:
> > 
> > Hello Thomas,
> > 
> > > Hi
> > > 
> > > Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
> > > > Hi
> > > > 
> > > > Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
> > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > 
> > > > > If 'info->screen_buffer' locates in vmalloc address space, virt_to_page
> > > > > will not be able to get correct results. With CONFIG_DEBUG_VM and
> > > > > CONFIG_DEBUG_VIRTUAL enabled on ARM64, there is dump below:
> > > > Which graphics driver triggers this bug?
> > > > 
> > > > > [??? 3.536043] ------------[ cut here ]------------
> > > > > [??? 3.540716] virt_to_phys used for non-linear address:
> > > > > 000000007fc4f540 (0xffff800086001000)
> > > > > [??? 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12
> > > > > __virt_to_phys+0x68/0x98
> > > > > [??? 3.565455] Modules linked in:
> > > > > [??? 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted
> > > > > 6.6.23-06226-g4986cc3e1b75-dirty #250
> > > > > [??? 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
> > > > > [??? 3.582452] Workqueue: events_unbound deferred_probe_work_func
> > > > > [??? 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> > > > > BTYPE=--)
> > > > > [??? 3.595233] pc : __virt_to_phys+0x68/0x98
> > > > > [??? 3.599246] lr : __virt_to_phys+0x68/0x98
> > > > > [??? 3.603276] sp : ffff800083603990
> > > > > [??? 3.677939] Call trace:
> > > > > [??? 3.680393]? __virt_to_phys+0x68/0x98
> > > > > [??? 3.684067]? drm_fbdev_dma_helper_fb_probe+0x138/0x238
> > > > > [??? 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
> > > > > [??? 3.695385]? drm_fb_helper_initial_config+0x4c/0x68
> > > > > [??? 3.700264]? drm_fbdev_dma_client_hotplug+0x8c/0xe0
> > > > > [??? 3.705161]? drm_client_register+0x60/0xb0
> > > > > [??? 3.709269]? drm_fbdev_dma_setup+0x94/0x148
> > > > > 
> > > > > So add a check 'is_vmalloc_addr'.
> > > > > 
> > > > > Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for
> > > > > GEM DMA helpers")
> > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > I'm taking back my r-b. The memory is expected to by be physically
> > > contiguous and vmalloc() won't guarantee that.
> > > 
> > Agreed.
> 
> These smem_ fields are clearly designed for PCI BARs of traditional graphics
> cards. So can we even assume contiguous memory for DMA? That was my
> assumption, but with IOMMUs it might not be the case. Fbdev-dma only sets
> smem_start to support a single old userspace driver. Maybe we should further
> restrict usage of this field by making it opt-in for each driver. Best
> regards Thomas

We could make it all conditional on CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM, and
remove the FBINFO_HIDE_SMEM_START flag. The reason I've done the flag is
that with the old fb_mmap code we had to always fill out smem_start to
make mmap work. But now that the various drm fbdev helpers have all their
own mmap implementation, we could make this a lot cleaner.

If I haven't missed anything, that is.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch