linux-kernel - Re: 3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq

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:	Tue, 25 Mar 2014 10:13:27 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Andreas Mohr <andi@...as.de>
Cc:	Mikulas Patocka <mpatocka@...hat.com>,
	Dave Airlie <airlied@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	DRI <dri-devel@...ts.freedesktop.org>
Subject: Re: 3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Tue, Mar 25, 2014 at 12:11 AM, Andreas Mohr <andi@...as.de> wrote:
> On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote:
>> On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka <mpatocka@...hat.com> wrote:
>> > If someone understands the locking issues I pointed out above, it could be
>> > easy to fix.
>>
>> The locking issue isn't your problem, the real issue is that putting a
>> irq_uninstall into core code will break all the new (properly working)
>> drivers. And you can't really fix this in mga itself since the
>> lifetime rules of the register mappings are totally broken. It's a
>> fundamental misdesign of the legacy drm driver architecture and the
>> _only_ way to fix this bug for real is to rewrite this all. Which was
>> done for all the still used drivers like i915, radeon, nouveau, ...
>
> That sounds plausible - yet with meatballs (ok, maybe I should omit
> such quite possibly unjustified qualification) such as this:
>
> git show --stat 771fe6b912fca54f03
>
> how is a bunch of marginally-trained hobbyists ever supposed to be implementing
> a working practical (i.e., "base") driver for *various* currently unsupported
> (booted would perhaps even be a more fitting word?) hardware?
>
> While the result of a wc -l check of the drivers/gpu/drm/r128 dir itself
> seems quite positive, that still might be not much of help
> when eyeing the large KMS changes that had to be done elsewhere.
>
> I guess we can make use of all the practical advice/links that we can get...
> (such as hints at good candidates of existing KMSified drivers
> which don't come with the full bells and whistles package,
> hints at suitably sized KMS support commits, grandma tutorials, ...).
> Some semi-short search wasn't overly successful, with links such as
> http://www.x.org/wiki/ModeSetting/
> https://en.wikipedia.org/wiki/KMS_%28Linux_kernel%29#Linux
> "New, Generic X.Org KMS Driver Work" http://www.phoronix.com/scan.php?page=news_item&px=OTk1OA
>
> Or perhaps I should just state outright that I seem to be in need
> of a working solution for my kernel upgrade pain
> which I would be deemed to want semi-soonish
> (the i810, MGA users and some others might be sharing my thoughts).
> IOW, my r128 driver is somewhat of a "still used driver", thank you very much.
>
> Thanks for having managed to survive my posting in an asbestos-lined
> garment (apologies if it came across in harsh terms :),
>
> Andreas Mohr
> (not necessarily a member of the forced-monopoly hardware upgrade treadmill cult)

Well I have a i810 here personally and since about 3 years haven't
gotten around to implement a kms stack for it (just for fun
essentially). And that's on a platform which can steal a lot of the
kms infrastructure from the i915 driver.

For simple devices getting a basic kms driver off the ground (that
means no accelaration support in the kernel with GEM, and obviously
userspace not ported) seems to be doable in one gsoc term, at least
someone managed it. Which means 3 months full-time work.

So yeah, writing real gpu drivers is fairly non-trivial task. And all
the people who can do it are fully busy getting the new shit to work.

Wrt stealing code: It's better to look at the legacy fbdev drivers,
since they have modeset support. And meanwhile we have fairly decent
drm DocBook in the kernel, the latest updates are in drm-next.
-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/