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: <20140324231130.GA1386@rhlx01.hs-esslingen.de>
Date:	Tue, 25 Mar 2014 00:11:30 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Mikulas Patocka <mpatocka@...hat.com>,
	Dave Airlie <airlied@...il.com>, Andreas Mohr <andi@...as.de>,
	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)

Hi,

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)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ