linux-kernel - Re: [git pull request] ACPI patches for 2.6.36.merge

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: <AANLkTi=Ok3NH3k5EF1Da2Z3xA7uahABRtH7pEdOEuZH2@mail.gmail.com>
Date:	Sun, 15 Aug 2010 14:04:09 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	sedat.dilek@...il.com, Andi Kleen <ak@...ux.intel.com>,
	len.brown@...el.com, Linux ACPI <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull request] ACPI patches for 2.6.36.merge

On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
>
> I'd be suspecting that we have two patches both of which worked
> separately but which broke when combined.  Is there some other patch in
> that tree which adds a new reference to `ref' in acpi_power_seq_show()?

The offending patch isn't about acpi_power_seq_show(), it's about
acpi_power_off_device().

But that may well explain the breakage: there does seem to be an
unused ref in acpi_power_seq_show() (around line 556). It's just that
the patch in question doesn't remove that one, it removes the
very-much-used one in acpi_power_off_device() (line 256 or so).

And the contexts don't even match. Well, they do match to 2 lines. But
they're not very close. However, Len's tree does have a patch to just
remove all the procfs crap, so acpi_power_seq_show() has gone away,
which I guess explains how the subsequent patch was then applied to
something it should never have been applied to. Probably with GNU
patch that doesn't mind the fact that it doesn't match exactly (or
somebody used git and explicitly said "apply it with fuzz").

So that seems to explain how the patch got corrupted.

But nothing explains the fact that clearly _zero_ testing was done.
The tree was clearly never even compiled. Len apparently did a blind
patch application (or rebase, or whatever), and never bothered to
compile the end result afterwards, just sent it to me sight-unseen.

What does that say about the _rest_ of the patches? What does that say
about (lack of) -next testing?

                         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/