linux-kernel - RE: Kernel marker has no performance impact on ia64.

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: <004101c8cd0c$aa093190$fe1b94b0$@css.fujitsu.com>
Date:	Fri, 13 Jun 2008 13:19:25 +0900
From:	"Takashi Nishiie" <t-nishiie@...css.fujitsu.com>
To:	"'Masami Hiramatsu'" <mhiramat@...hat.com>,
	"'Frank Ch. Eigler'" <fche@...hat.com>
Cc:	"'Peter Zijlstra'" <peterz@...radead.org>,
	"'Mathieu Desnoyers'" <mathieu.desnoyers@...ymtl.ca>,
	"'Hideo AOKI'" <haoki@...hat.com>, <mingo@...e.hu>,
	<linux-kernel@...r.kernel.org>,
	"'Steven Rostedt'" <rostedt@...dmis.org>
Subject: RE: Kernel marker has no performance impact on ia64.

Hi,Hiramatsu

 Hiramatsu wrote:

>I think if someone changes the trace point in the kernel,
>Module.markers is also changed.
>
>ex.)
> DEFINE_TRACE(sched_switch, (struct task_struct * next, struct task_struct
* prev),
>	     next, prev);
>
>if someone changes above to below,
>
> DEFINE_TRACE(sched_switch, (int prev_pid, int next_pid), prev_pid,
next_pid);
>
>Module.markers also change like
>
> sched_switch	vmlinux	(struct task_struct * next, struct task_struct *
prev)
>
>to
>
> sched_switch	vmlinux	(int prev_pid, int next_pid)
>
>In this case, the below entry never matches to new Module.markers.
>
>"sched_switch(struct task_struct * next, struct task_struct * prev)":"next
%p prev %p"
>
>Thus, we can find an error.
>However, of cause, we should take care of the task_struct changes.

  The one expected of markers with SystemTap and LTTng is only 
different the foundation of this discussion. 

SystemTap:
  Because the output format is basically defined with user script in 
systemtap script, "format information" is unnecessary. It can do 
nothing but guess from "format information" in present markers though 
the type of the argument is indispensable for SystemTap on the other 
hand. If the type of an accurate argument is understood, correct 
processing can be executed. Moreover, being able to refer to the 
member of the structure if the argument is a pointer of the structure 
becomes possible, and it is convenient. 

LTTng:
  Because the output format is not originally defined in LTTng, "format 
information" is indispensable. 

  I think that I only have to add the item that shows the type of an 
accurate argument if the format of "Module.markers" is changed. 

Thank you,

--
Takashi Nishiie

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