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: <AANLkTik8-=Ku+4k0+KVZknAgx2zJGRo-n10jaNW-fke6@mail.gmail.com>
Date:	Fri, 12 Nov 2010 08:24:48 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>,
	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie <airlied@...ux.ie> wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.

Btw, Chris - don't do this:

  commit 08deebf98783d3de553eed2c9b6b8dcc7e168567
  Author: Chris Wilson <chris@...is-wilson.co.uk>
  Date:   Fri Nov 5 08:56:38 2010 +0000

    drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism

    My Sandybridge only reports 0 for the ring buffer registers, causing it
    to hang as soon as we exhaust the available ring. As a workaround, take
    advantage of our huge ring buffers and use the auto-reporting mechanism
    to update the status page with the HEAD location every 64 KiB.

    Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d.

    ...

Think about what that "Cherry-picked from 6aa56062eaba.." means for a while.

It's a totally random number that is entirely pointless. That commit
doesn't exist in any trees anybody else is aware of, so it's pure and
utter noise. It has no meaning.

The only SHA1 numbers that are meaningful are numbers that are in some
history that is relevant. So a SHA1 should normally only ever point to
a commit that exists in the history of the commit that it points to
(think reverts, or "this fixes an issue introduced in xyz"). So if you
see that commit description, you're pretty much guaranteed that the
SHA1 makes sense.

The one exception is when you point to some "known external tree" - ie
the stable tree has references to the commits in the upstream kernel,
even though they are obviously not in the history of the stable commit
itself. The numbers may not make sense within the confines of just the
stable tree at the time, but at the same time, the stable tree rules
are very much that commits only get in once they are in mainline, so
there are actual rules in place basically saying that the hash makes
sense even _if_ it refers to an outside tree.

But when you cherry-pick it from some random internal tree that nobody
will necessarily ever see, and that you don't even describe what it
is, it's only pure confusion. I do

  [torvalds@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
  fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d

and so will everybody else. So from a documentation standpoint, you're
actually adding negative information. Please don't.

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