linux-kernel - Re: [REGRESSION] v3.12-rc1: i915_driver

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]

Date:	Sat, 7 Sep 2013 16:30:03 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Tom Gundersen <teg@...m.no>
Cc:	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

Hi Tom

On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann <dh.herrmann@...il.com> wrote:
> Hi
>
> On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen <teg@...m.no> wrote:
>> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann <dh.herrmann@...il.com> wrote:
>>>
>>> It seems to be unrelated to the x86-sysfb changes. The WARN_ON
>>> triggered here obviously means that i915 remaps VMEM before removing
>>> efifb. So either i915 now calls ioremap and friends _before_ calling
>>> remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
>>
>> I redid all the tests, and I'm now not able to reproduce this with
>> efifb, only with simplefb (not sure if I made a mistake before or if
>> some config changed). I attached the two different dmesg outputs (only
>> difference is X86_SYSFB).
>>
>>> Tom, some things off the top of my head:
>>> - Is efifb still running after i915 loaded? You can see that via:
>>>   cat /sys/class/graphics/fb0/name
>>>   (and also fb1, fb2, ... whatever is there)
>>>   If it's not running, anymore, then it's quite likely an i915 issue.
>>
>> I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this
>> is after i915 has taken over from simplefb).
>>
>>> - Do you get a "fb: conflicting hw usage ..." in your dmesg log?
>>
>> Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing
>> generic driver"
>
> Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback
> so it does not correctly react to remove_conflicting_framebuffer().
> But you can safely ignore the warning as simplefb is still unloaded.
> So it cannot be accessed anymore. It just leaks the remapping.
>
> I will send a patch later today which adds the fb_destroy() callback.

Attached are two patches. The first one should fix this issue, the
second one is the rebased ioremap_wc() patch from the other thread.

Does this fix the issue (and the speed-problems)?

Thanks
David

Download attachment "0001-simplefb-fix-unmapping-fb-during-destruction.patch" of type "application/octet-stream" (5220 bytes)

Download attachment "0002-simplefb-use-write-combined-remapping.patch" of type "application/octet-stream" (1227 bytes)