linux-kernel - Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp

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-next>] [day] [month] [year] [list]

Date:	Thu, 18 Apr 2013 21:48:06 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Sedat Dilek <sedat.dilek@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next <linux-next@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	x86@...nel.org, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Paul McKenney <paul.mckenney@...aro.org>,
	DRI <dri-devel@...ts.freedesktop.org>,
	Dave Airlie <airlied@...hat.com>
Subject: Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu
 related? ]

On Thu, Apr 18, 2013 at 3:05 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Thu, Apr 18, 2013 at 10:28 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>> Hi all,
>>
>> Changes since 20130417:
>>
>> New Trees:      rpmsg (actually added yesterday)
>>                 ppc-temp (replacing powerpc for this week)
>>
>> The ceph tree gained a conflict against Linus' tree.
>>
>> The net-next tree gained a conflict against the infiniband tree.
>>
>> The usb tree gained a build failure so I used the version from
>> next-20130417.
>>
>> I added two merge fix patches after the gen-gpio tree.
>>
>> The ppc-temp tree gained a conflict against the metag tree.
>>
>> The akpm tree lost a patch that turned up elsewhere.
>>
>> ----------------------------------------------------------------------------
>>
>
> Not sure what the root-cause for this call-trace is (see screenshot).
>
> This is reproducible when running my kernel build-script (4 parallel-make-jobs).
>
> Any hints welcome!

The panic handlers in our modeset code are pretty decent fubar - they
take mutexes all over the place. So I think the backtrace you see
there is actually a secondary effect. I've looked into fixing this up,
but the issue is that drivers themselves have tons of state protected
with mutexes, which all potentially affects the panic handler. So I've
given up on that for now ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/