linux-kernel - Re: x86 status was Re: -mm merge plans for 2.6.23

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: <alpine.LFD.0.999.0707111524510.20061@woody.linux-foundation.org>
Date:	Wed, 11 Jul 2007 15:33:07 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Valdis.Kletnieks@...edu
cc:	Chris Wright <chrisw@...s-sol.org>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: x86 status was Re: -mm merge plans for 2.6.23

On Wed, 11 Jul 2007, Valdis.Kletnieks@...edu wrote:
> 
> <Takes a closer look at the patches>  D'Oh! :)  Yeah, the -rc4 version I'm
> looking at is like a dozen 1-3K patches setting up and cleaning up, and then
> one monster 65K patch doing the clockevents conversion, then another 6 or 8
> small ones.
> 
> Yeah, that one big patch really doesn't look separable to me. 

I think it should be.

That big patch really does do a *lot* more than just the "clockevents 
conversion". It does all the hpet clock setup changes etc that are about 
the hardware, and have *nothing* to do with actually changing the 
interfaces.

For example, look at the hpet.c part of that patch. Totally independent 
cleanups of everything else.

Or look at the changes to __setup_APIC_LVTT(). Same thing. 

All the actual hardware interface changes are *totally* independent of the 
software interface changes, and a lot of them are just cleanups.

But those hardware interface changes are easily the things that can break, 
where some cleanup results in register writes being done in a different 
order or something, and so if there's a bug there (and it's not visible on 
most setups), now you cannot tell where the bug is.

Another example: setup_APIC_timer() used to wait for a timer interrupt 
trigger to happen on the i8259 timer (or HPET). That code just got 
removed (or maybe it got moved so subtly that I just don't see it). 

What has that got to do with switching from the old timer interface to the 
new one?

NOTHING.

So those kinds of changes that change hardware access functions should 
have been done separately. Maybe there's a machine where that early 
synchronization was necessary for some subtle timing reason. If so, 
removing it sounds like a bug, no? Wouldn't it have been nice to see that 
removal as a separate patch that was independent of the interface switch- 
over?

I'd be a *lot* happier with switching over interfaces if I thought that 
the low-level hardware drivers didn't change at the same time. But they 
*do* change, afaik.

		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/