linux-kernel - Re: [drm] BUG: spinlock lockup suspected on CPU#0, swapper/0/1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 14 Jan 2014 15:16:49 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Dave Airlie <airlied@...il.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [drm] BUG: spinlock lockup suspected on CPU#0, swapper/0/1

Hi

On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu <fengguang.wu@...el.com> wrote:
> Hi David,
>
> I'm not sure if this is a good bisect because the errors are noisy,
> however it's good to inform you of this possibility.
>
> First bad commit may be a3483353c ("drm: check for !kdev in drm_unplug_minor()")

To be honest, I doubt that it's somehow related to this commit. We
replace "!device_is_registered(minor->kdev)" with a "!minor->kdev".
Both of these expressions have no side-effects (especially the latter
one) and they only evaluate to true during DRM unplugging. Having said
that, your log also contains this:

[   12.058502] [drm] Initialized drm 1.1.0 20060810
[   12.059918] [drm] radeon kernel modesetting enabled.
[   12.061791] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
[   12.063409] cirrus 0000:00:02.0: Fatal error during GPU init: -6
[   12.064914] Trying to free nonexistent resource <00000000febf0000-000000=
00febf0fff>

The DRM cirrus driver fails to load and given the error message I
suspect the error-path is not clean. Dave Airlie should know more
about cirrus, but I really think this is related to cirrus not
correctly cleaning up it's resources. Dave, any ideas? Disbling
CONFIG_CIRRUS should be a good workaround, in case anyone cares.

The commit in question highly reduces the required stack-space during
DRM unload (which includes the cirrus error-path) so I think the
bisect was alright, but the commit is not the actual culprit. It just
reveals some stack-corruption, I guess.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/