lkml.org 
[lkml]   [2017]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2
On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>
> This patch triggers a NULL-dereference bug at update_stack_state().
> Although its parent commit also has a NULL-dereference bug, however
> the call stack looks rather different. Both dmesg files are attached.
>
> It also triggers this warning, which is being discussed in another
> thread, so CC Josh. The full dmesg attached, too.
>
> Please press Enter to activate this console.
> [ 138.605622] WARNING: kernel stack regs at be299c9a in procd:340 has bad 'bp' value 000001be
> [ 138.605627] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0
> [ 138.605631] be299c9a: 299ceb00 (0x299ceb00)
> [ 138.605633] be299c9e: 2281f1be (0x2281f1be)
> [ 138.605634] be299ca2: 299cebb6 (0x299cebb6)
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit b09be676e0ff25bd6d2e7637e26d349f9109ad75
> locking/lockdep: Implement the 'crossrelease' feature

Can we consider just reverting the crossrelease thing?

The apparent stack corruption really worries me, and what worries me
most is that commit wasn't even supposed to change anything as far as
I can tell - it only adds infrastructure, no actual users that *set*
the cross-lock thing.

So the fact that it actually seems to cause behavioural changes seems
to be _really_ scary, and indicates that the code is completely
broken.

Or am I missing something?

Linus

\
 
 \ /
  Last update: 2017-10-03 18:55    [W:0.170 / U:2.256 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site