linux-kernel - Re: [PATCH 0/3] jump label: updates for 2.6.37

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]

Date:	Tue, 23 Nov 2010 18:10:54 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jason Baron <jbaron@...hat.com>
Cc:	mingo@...e.hu, peterz@...radead.org, mathieu.desnoyers@...ymtl.ca,
	hpa@...or.com, tglx@...utronix.de, andi@...stfloor.org,
	roland@...hat.com, rth@...hat.com, masami.hiramatsu.pt@...achi.com,
	fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
	sam@...nborg.org, ddaney@...iumnetworks.com,
	michael@...erman.id.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] jump label: updates for 2.6.37

On Tue, 2010-11-23 at 16:56 -0500, Jason Baron wrote:
> On Tue, Nov 23, 2010 at 04:42:07PM -0500, Steven Rostedt wrote:
> > On Tue, 2010-11-23 at 16:27 -0500, Jason Baron wrote:
> > > Hi,
> > > 
> > > A few jump label patches that I want considered for 2.6.37. Patches are against
> > > the latest -tip tree.
> > 
> > I can see patch 2 and 3 going to 2.6.37, but patch 1 seems a bit too
> > big. If it is not a true fix for anything and is just a design change,
> > then lets hold off till 2.6.38.
> > 
> > 
> > > 
> > > The first one, which adds 'state' to the jump label mechanism is the most
> > > important. Essentially, it ensures that if jump labels are enabled/disabled in
> > > the core kernel but the actual call sites are in modules, we properly honor the
> > > state of the jump label. This also works for jump labels which may be defined in
> > > one module but made use of in another module.
> > 
> > What happens if we don't do this. What does "honoring" the state
> > actually mean?
> > 
> 
> So for example, let's say we do:
> 
> 1) echo 1 > /sys/kernel/debug/tracing/events/kmem/kmalloc/enable
> 2) load module 'A' that has the 'kmalloc' tracepoint.
> 
> Without patch #1, we would fail to trace the 'kmalloc' in module 'A'.
> The only way to get the output from the 'kmalloc' tracepoint in module
> 'A', would be to issue the echo command again.
> 
> To me this is a correctness patch, and should be included.
> 

It's not what you think that matters, it's what Linus thinks ;-)
He just wants bug fixes.

Anyway, I just tried what you explained with the current kernel, with
and without jump labels and, without jump labels, the module has its
kmalloc tracepoint traced, but with jump labels it does not. So we can
treat this as a regression, which is something that can go into an -rc.

The change log must state that this _is_ a regression, or Linus may not
accept it.

I'll test out your patches.

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