linux-kernel - RE: [PATCH RESEND 0/2] tracing: signal tracepoints

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] [day] [month] [year] [list]

Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2C57FFA27F@USINDEVS01.corp.hds.com>
Date:	Mon, 19 Dec 2011 12:28:11 -0500
From:	Seiji Aguchi <seiji.aguchi@....com>
To:	Oleg Nesterov <oleg@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH RESEND 0/2] tracing: signal tracepoints

Hi,

Thanks, Oleg.

This patchset is helpful for me.

When some applications fail to send signal, our customers sometimes ask its reason to us.
With this patchset, we can know behavior of signal event in detail and explain it to them.

Seiji

>-----Original Message-----
>From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Oleg Nesterov
>Sent: Monday, December 19, 2011 12:05 PM
>To: Steven Rostedt; Ingo Molnar; Andrew Morton
>Cc: Frederic Weisbecker; Jiri Olsa; Masami Hiramatsu; Seiji Aguchi; linux-kernel@...r.kernel.org
>Subject: [PATCH RESEND 0/2] tracing: signal tracepoints
>
>Steven, sorry for delay...
>
>On 12/02, Steven Rostedt wrote:
>>
>> On Tue, 2011-11-22 at 21:52 +0100, Oleg Nesterov wrote:
>> >
>> > > 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.
>
>Yes, yes, I see. But I do not see any alternative. Of course, instead
>of adding "int result" we could add more trace_signal_generate's into
>the code, but imho this is too ugly. And in fact I am not sure this
>means less overhead with CONFIG_TRACE* even if this code is nop'ed.
>
>> 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.
>
>I simply do not know. I _think_ that the overhead is negligible, the
>extra calculating just adds a couple of "mov CONSTANT, REGISTER" insns.
>
>> > 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.
>
>OK, thanks.
>
>The next question is, how can I add it ;) May be Ingo or Andrew could
>take these patches? Original signal tracepoints were routed via tip-tree...
>
>Add them both to TO:, lets see who is kinder.
>
>
>> > 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>
>
>Thanks, included.
>
>Oleg.
>
>--
>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/
--
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/