From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@bugzilla.kernel.org
Subject: [Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
Date: Mon, 12 Aug 2013 01:51:44 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path:
Received: from mail.kernel.org (mail.kernel.org [198.145.19.201])
by gabe.freedesktop.org (Postfix) with ESMTP id 98AE9E64E1
for ;
Sun, 11 Aug 2013 19:20:08 -0700 (PDT)
Received: from mail.kernel.org (localhost [127.0.0.1])
by mail.kernel.org (Postfix) with ESMTP id 39ADC202AC
for ;
Mon, 12 Aug 2013 01:51:47 +0000 (UTC)
Received: from bugzilla2.web.kernel.org (bugzilla2.web.kernel.org
[172.20.200.52])
by mail.kernel.org (Postfix) with ESMTP id D7B1620266
for ;
Mon, 12 Aug 2013 01:51:44 +0000 (UTC)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
https://bugzilla.kernel.org/show_bug.cgi?id=16193
Scott Wood changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |scott@buserror.net
--- Comment #3 from Scott Wood ---
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()?
--
You are receiving this mail because:
You are watching the assignee of the bug.