linux-kernel - Re: [Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free

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

Message-ID: <20150317075321.GM21993@phenom.ffwll.local>
Date:	Tue, 17 Mar 2015 08:53:21 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Daniel Vetter <daniel@...ll.ch>,
	Andrey Skvortsov <andrej.skvortzov@...il.com>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, Sitsofe Wheeler <sitsofe@...il.com>
Subject: Re: [Intel-gfx] [Regression] WARNING:
 drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

On Mon, Mar 16, 2015 at 01:21:58PM -0400, Steven Rostedt wrote:
> On Mon, 16 Mar 2015 17:43:33 +0100
> Daniel Vetter <daniel@...ll.ch> wrote:
> 
> 
> > Is linux-next also affected or is this just a case of i915 maintainers
> > having failed to push the right patch to -fixes?
> 
> I just confirmed, linux-next boots without the warning.
> 
> > 
> > I'll try to figure out what fell apart here meanwhile. To help out, can
> > you please boot with drm.debug=0xe and grab the full dmesg for booting?
> > Looks like it falls over in the initial fbcon modeset, which is indeed
> > strange ...
> 
> Here they are:
> 
>  http://rostedt.homelinux.com/private/dmesg-next
> 
>  http://rostedt.homelinux.com/private/dmesg-4.0

The unnerving part is that I didn't find any patch not anything else that
might fix this frontbuffer_bits leak. I also couldn't spot the bug.

The real reason why -next works and 4.0 doesn't seems to be that 4.0
reconstructs a bogus initial framebuffer and then falls over when cleaning
that up. -next just doesn't reconstruct that framebuffer and hence also
can't fall over on cleanup.

Can you please cherry pick 42a7b088127f (\"drm/i915: Make sure the primary
plane is enabled before reading out the fb state\") from -next to 4.0-rc
to test whether this is indeed the difference in ducttape?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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/