linux-kernel - Re: [git pull] drm fixes

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: <1301039010.12159.56.camel@thor.local>
Date:	Fri, 25 Mar 2011 08:43:30 +0100
From:	Michel Dänzer <michel@...nzer.net>
To:	Dave Airlie <airlied@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Fre, 2011-03-25 at 17:21 +1000, Dave Airlie wrote: 
> On Fri, Mar 25, 2011 at 10:17 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie <airlied@...il.com> wrote:
> >>
> >> Like seriously you really think VFS locking rework wasn't under
> >> development or discussion when you merged it? I'm sure Al would have
> >> something to say about it considering the number of times he cursed in
> >> irc about that code after you merged it.
> >
> > Umm. That code was basically over a year old by the time it was merged.
> >
> > How old was the code we're talking about now? Seriously?
> 
> It was 30 lines of clean code, that really was fine to be merged in
> its first form it was merely a future maintaince issue to clean up the
> interface before it was released as stable.

>From my POV the real failure here was that the change made it to *any*
tree while there were outstanding review issues from when it was
initially discussed a few weeks earlier. Then when the change was
submitted — more or less unchanged — I was on my birthday weekend
enjoying some time away from computers, and when I had caught up with
things, it was already in drm-next.


> In this case, if you had a >2 monitor setup connected to an evergreen
> card, and you tried to do 3D on the 3rd monitor it would just hang the
> app in a loop forever, the fix needs 3 pieces, one in the kernel, and
> two userspace fixes.

Actually, the hangs could be fixed in the X driver alone, but the author
seems uninterested in contemplating that. Maybe because he seems to
think it's easier to get the kernel fix to users, but I'm with you on
that it's quite clearly the opposite.


That said, I agree with your analysis in general, but not in this
particular case.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--
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/