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 16:56:04 -0500
From:	Jason Baron <jbaron@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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, 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.

thanks,

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