linux-kernel - Re: [PATCH 0/2] (Was: Q: tracing: can we change trace_signal

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: <1322848385.30977.50.camel@frodo>
Date:	Fri, 02 Dec 2011 12:53:05 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] (Was: Q: tracing: can we change
 trace_signal_generate() signature?)

On Tue, 2011-11-22 at 21:52 +0100, Oleg Nesterov wrote:
> O
> > Is "result" used for anything but tracepoints? When tracing is disabled,
> > the tracepoints should be just nops (when jump_label is enabled). Thus
> > tracing is very light. But if we are constantly calculating "result",
> > this is unused by those that don't use the tracing infrastructure, which
> > is 99.99% of all users. This is what I meant.
> 
> Ah I see. I thought you dislike OVERFLOW_FAIL/LOSE_INFO namely.
> 
> Of course, you are right. OTOH, this patch shaves 1058 bytes from
> .text. And without CONFIG_TRACE* gcc doesn't generate the extra code.

I was just noting that when tracing is disabled (CONFIG_TRACE* is set,
like it is on distros, but tracing is not happening), that we have extra
code. We usually strive to have tracing configured into the kernel, but
produces no (actually as little as possible) overhead when not actively
tracing.

That said, you know this code much more than I do. If this isn't a fast
path, and spinning a few more CPU cycles and perhaps dirtying a few
cache lines floats your boat. I'm OK with this change.

> 
> 
> 
> Oh. I simply do not know what can I do. Obviously, I'd like to avoid
> the new tracepoints in __send_signal(), imho this would be ugly. But
> the users want more info.
> 
> OK. let me send the patch at least for review. May be someone will
> nack it authoritatively, in this case I can relax and forward the
> nack back to bugzilla ;)

Again, if you don't think adding very slight overhead to this path is an
issue. Go ahead and add it.

> 
> However, at least 2/2 looks very reasonable to me. In fact it looks
> almost like the bug-fix.

2/2 looks to have the extra overhead to. Is the bug fix just with the
trace point.

Again, if you don't mind the overhead, then here:

Acked-by: Steven Rostedt <rostedt@...dmis.org>

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