linux-kernel - Re: [git pull] drm merge for 3.9-rc1

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: <CAPM=9tyY4_wN_XyHu09BXZAewq3DU8t2RTMq4zbr5URLnFSJbw@mail.gmail.com>
Date:	Tue, 26 Feb 2013 11:59:13 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...ux.ie>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm merge for 3.9-rc1

>
> I did the fun conflict resolution, so my tree doesn't have the ordering changes.
>
> I also did some things slightly differently from you - you had left
> some direct ib[] accesses that I spotted (see for example "case 0x48"
> (aka "Copy L2T Frame to Field"), and yours apparently has a few cases
> where you use "idx_value" instead of my mindless conflict resolution
> that just re-did the brute-force "repace direct ib[] read accesses
> with the radeon_get_ib_value() helper function". But you don't do it
> for *all* the radeon_get_ib_value(p, idx+2) users, so whatever.

Yeah the rules for radeon_get_ib_value are that they are meant to be sequential,
but it actually doesn't matter as long as the values are within a page
of each other,
I was just avoiding multiple calls to get the same value with the idx_value, but
I think Alex or Jerome can clean this up a bit further anyways.

> Anyway - my conflict resolution isn't exactly the same as yours, and
> maybe I screwed something up. But it's damn close, and the differences
> _seem_ be all be benign.
>
> Btw, why is it ok that some functions still read the ib[] array
> directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg()
> etc)?

The semantics for that function are a bit underdocumented, and I thought
the other developers understood them after I explained them, but I found
out that they hadn't quite grasped the true extent of pain. So yes there
are other places that need to be cleaned up, but most of the time direct
ib access will work fine, until you have a buffer that straddles a
page boundary.

> Whatever. I prefer doing my own resolutions just so that I know what's
> going on, and it all seems to build and looks reasonable, but it's
> always good to get a second opinion. Particularly since I can't
> actually test the radeon stuff, so just eyeballing it and saying
> "looks semantically identical to Dave's resolution" may not be 100%
> sufficient..

Yup I've reviewed it and it looks fine, any cleanup is just going to be
an optimisation.

So I'll work with Alex/Jerome to clean up anything else out-of-band
and hopefully
we can avoid any big conflicts in future!

Dave.
--
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/