linux-kernel - Re: Fix powerTOP regression with 2.6.39-rc5

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: <1304716255.25414.2540.camel@gandalf.stny.rr.com>
Date:	Fri, 06 May 2011 17:10:55 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Fix powerTOP regression with 2.6.39-rc5

On Fri, 2011-05-06 at 13:51 -0700, Linus Torvalds wrote:
> On Fri, May 6, 2011 at 1:20 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > I strongly NACK this!
> 
> Doesn't matter.
> 
> Binary compatibility is more important.
> 
> And if binaries don't use the interface to parse the format (or just
> parse it wrongly - see the fairly recent example of adding uuid's to
> /proc/self/mountinfo), then it's a regression.
> 
> And regressions get reverted, unless there are security issues or
> similar that makes us go "Oh Gods, we really have to break things".

Um, this is an internal tracepoint. Does this mean that all internal
data inside the kernel that is exported with trace events are locked
down?

> 
> I don't understand why this simple logic is so hard for some kernel
> developers to understand. Reality matters. Your personal wishes matter
> NOT AT ALL.

This isn't a personal wish. This brings every advancement that I was
planning on making this year to a dead halt. We were really about to
restructure the events to make them lighter weight and faster.

Also, this isn't the first time this structure has changed. It just
happens that something started using it. This field did not even exist
until recently.

> 
> If you made an interface that can be used without parsing the
> interface description, then we're stuck with the interface. Theory
> simply doesn't matter.

I never had an interface used this way. It was just by luck. Damn, I
should have listened to Peter Zijlstra when he recommended that every
boot restructures the data in the format differently. Then this would
never have happened. But doing that would have slowed things down
tremendously (or remove the ease of TRACE_EVENT).

> 
> You could help fix the tools, and try to avoid the compatibility
> issues that way. There aren't that many of them.

As I said, I have a library (.so even) that does the parsing for you. If
I get powertop to use it, can we hold off on this patch?

Note, I'm about to leave to Budapest. I could try to get this done on
the trip.

-- Steve

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