linux-kernel - Re: -mm merge plans for 2.6.20

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: <1165393929.24604.222.camel@localhost.localdomain>
Date:	Wed, 06 Dec 2006 09:32:09 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Morton <akpm@...l.org>
Cc:	Roman Zippel <zippel@...ux-m68k.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: -mm merge plans for 2.6.20

On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote: 
> I don't have a clue which review comments remain unaddressed - do you recall?
> 
> I never saw an item-by-item accounting of my own (extensive) review
> comments, actually.  And then an avalanche of new stuff got sent and I
> didn't have time to go through it all at the same level of detail.

Arjan did a review of the replacement and I'm in the process to go
through that and Romans comments again. I'll add a complete list of the
review issues and the resolution state. Sorry that this was delayed, but
I was busy regression testing and hunting nasty details in the last
weeks.

> So yeah, I don't have a lot of confidence from that POV either.  But otoh,
> I'm confident that Ingo and Thomas will competently and promptly address
> regressions, so the risk factor isn't too bad.  And changing APIC and
> timekeeping code sure is risky.

Timekeeping is mostly untouched and the APIC change was done to solve
real world issues:

- lapic verification gets stuck for ever
- lapic timer runs too fast

> > In the long term IMO this might need a major rework, the basic problem I 
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
> > to dynamically manage multiple timer.
> 
> I'm not sure I understand that.  Are you referring to multiple,
> concurrently-operating hardware clock sources?  <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

If I understand it correctly, Roman wants clockevents to be usable for
other things aside hrtimer/dyntick, i.e. let other code request unused
timer event hardware for special purposes. I thought about that in the
originally but I stayed away from it, as there are no users at the
moment and I wanted to avoid the usual "who needs that" comment. Granted
that clockevents is not perfect, but it's rather self contained and has
no user space exposure, so it can be replaced by something better
anytime.

	tglx

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