Bug 16193

Summary:	NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
Product:	Drivers	Reporter:	Tormod Volden (bugz.kernel.tormod)
Component:	Video(DRI - non Intel)	Assignee:	drivers_video-dri
Status:	RESOLVED OBSOLETE
Severity:	normal	CC:	alan, scott
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.35-rc3	Subsystem:
Regression:	No	Bisected commit-id:

Description Tormod Volden 2010-06-13 12:39:16 UTC

I was testing the game Lugaro on M26 (RV410), switching between different resolutions in the game's options menu. The LCD native 1680x1050 made the game cursor very slow, so I chose 1400x1050 (have to quit the game and reenter to take effect). After that I could not go back to 1024x768 (default, works well), only 1400++ resolutions were listed. Then suddenly X froze, but sysrq-B worked.

I am not sure if this is a recent regression, because it is the first time I try out different resolutions in this game, and the issue might not be easy to reproduce as it happened after a series of resolution switching.

Comment 1 Tormod Volden 2010-06-13 12:40:50 UTC

BTW, I was using mesa classic from git.

Comment 2 Alan 2012-11-05 14:16:22 UTC

Closing as obsolete. If this is still seen on modern kernels (3.2+) please update/reopen

Comment 3 Scott Wood 2013-08-12 01:51:44 UTC

I saw this (or something very similar) on Ubuntu's 3.8.0-27 kernel (but I hope this is useful information anyway -- I doubt it's an Ubuntu issue, and this code doesn't appear to have changed since 3.8), when using alt-enter to toggle fullscreen in dosbox (which worked many times in the past, so it's not easily reproduceable).

The NULL pointer is in rdev->gem.objects.  I notice that elsewhere, rdev->gem.mutex is held when the list is modified, but it does not appear to be held when traversed in radeon_unmap_vram_bos().  Will ttm_bo_unmap_virtual() ever acquire gem.mutex itself (i.e. can bo->destroy() be called)?  It wasn't immediately obvious that it would from reading the code, but if ttm_bo_unmap_virtual() can't cause list entry deletion then why use list_for_each_entry_safe()?  Is there something else that ensures that the list won't be modified concurrently with radeon_unmap_vram_bos()?