linux-kernel - Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

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

Message-ID: <20171231231725.3ihsr6k7socprmap@D-69-91-141-110.dhcp4.washington.edu>
Date:   Sun, 31 Dec 2017 18:17:25 -0500
From:   Alexandru Chirvasitu <achirvasub@...il.com>
To:     Chris Wilson <chris@...is-wilson.co.uk>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        intel-gfx@...ts.freedesktop.org,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Compiled a couple of kernels with kasan enabled. I don't yet have a
crash, but on the system that has been crashing I have the following
kasan distress signals on bootup (dmesg attached):

[    0.027746] ==================================================================
[    0.027759] BUG: KASAN: use-after-free in kernel_poison_pages+0xa6/0x140
[    0.027765] Write of size 4096 at addr ffff88080b390000 by task swapper/0/1

[    0.027774] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc5-x-void #1
[    0.027775] Hardware name: Notebook                         N24_25BU/N24_25BU, BIOS 5.12 02/17/2017
[    0.027776] Call Trace:
[    0.027782]  dump_stack+0x5c/0x7a
[    0.027785]  print_address_description+0x6b/0x290
[    0.027787]  kasan_report+0x28f/0x380
[    0.027790]  ? kernel_poison_pages+0xa6/0x140
[    0.027792]  memset+0x1f/0x40
[    0.027795]  kernel_poison_pages+0xa6/0x140
[    0.027798]  __free_pages_ok+0x14c/0x460
[    0.027802]  release_pebs_buffer+0xae/0xd0
[    0.027804]  release_ds_buffers+0x9c/0x110
[    0.027808]  x86_release_hardware+0x86/0xa0
[    0.027810]  hw_perf_event_destroy+0xa/0x20
[    0.027813]  _free_event+0x179/0x540
[    0.027816]  perf_event_release_kernel+0x21e/0x3a0
[    0.027819]  ? perf_event_create_kernel_counter+0x15a/0x190
[    0.027823]  hardlockup_detector_perf_init+0x2c/0x3c
[    0.027826]  lockup_detector_init+0x24/0x7e
[    0.027829]  kernel_init_freeable+0x152/0x2f5
[    0.027831]  ? rest_init+0xd0/0xd0
[    0.027833]  kernel_init+0xf/0x11a
[    0.027835]  ? rest_init+0xd0/0xd0
[    0.027837]  ret_from_fork+0x1f/0x30

[    0.027842] The buggy address belongs to the page:
[    0.027848] page:00000000ae05d3d5 count:0 mapcount:0 mapping:          (null) index:0x0
[    0.027854] flags: 0x17ffe0000000000()
[    0.027860] raw: 017ffe0000000000 0000000000000000 0000000000000000 00000000ffffffff
[    0.027867] raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
[    0.027872] page dumped because: kasan: bad access detected

[    0.027878] Memory state around the buggy address:
[    0.027883]  ffff88080b38ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.027889]  ffff88080b38ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.027895] >ffff88080b390000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    0.027900]                    ^
[    0.027904]  ffff88080b390080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    0.027912]  ffff88080b390100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    0.027917] ==================================================================
[    0.027923] Disabling lock debugging due to kernel taint





I'll follow up on the crashes when they happen, but I thought this
might be of some use.

Incidentally, I've compiled two kernels with kasan on: one using the
bad system's config (with make oldconfig), and one using the one on
the system that doesn't crash on the same machine.

The latter does *not* spit out the trace in dmesg (regardless of which
system I boot it on), while the former only complains on the bad
system (boots fine on the good OS).

So it must be specific to the kernel configuration + kernel
parameters, but I don't know how. I haven't mesed with the kernel
parameters myself: they are whatever the two respective GRUB
installations came with by default on the two systems.

I can attach whatever's needed and try out whatever you think might be
helpful, but I figured I'd keep the message light with just the kasan
trace dmesg attachment.



On Sun, Dec 31, 2017 at 04:54:14PM +0000, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2017-12-31 16:52:36)
> > I see lockdep is configured (though I'm not familiar with the feature;
> > the config came with it, and I made oldconfig), but I'll need to
> > recompile for kasan.
> > 
> > I'll do that over the next few days, but once done, what would I get
> > back to you with? Again logs if / when the problem occurs? I'm still
> > unable to trigger it reliably.
> 
> The new dmesg, I expect kasan will print a few warnings before it oopses
> again.
> -Chris

View attachment "void-log-void-cfg" of type "text/plain" (56367 bytes)