linux-kernel - [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: <20111122205239.GA20971@redhat.com>
Date:	Tue, 22 Nov 2011 21:52:39 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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: [PATCH 0/2] (Was: Q: tracing: can we change
	trace_signal_generate() signature?)

On 11/21, Steven Rostedt wrote:
>
> On Mon, 2011-11-21 at 21:21 +0100, Oleg Nesterov wrote:
>
> > Heh. How can I do this? The only thing I can do is: send the patch
> > to the maintainer - you ;)
> >
> > OK. I'll send the patch "officially" tomorrow, let's see who nacks it.
>
> I only maintain the tracing infrastructure. The tracepoint users are
> maintained by the subsystem they are used in. Who's the signal
> maintainer? ;)

You are trolling me ;)

> > > > @@ -1095,14 +1106,15 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> > > >  			 * signal was rt and sent by user using something
> > > >  			 * other than kill().
> > > >  			 */
> > > > -			trace_signal_overflow_fail(sig, group, info);
> > > > -			return -EAGAIN;
> > > > +			result = TRACE_SIGNAL_OVERFLOW_FAIL;
> > > > +			ret = -EAGAIN;
> > > > +			goto ret;
> > > >  		} else {
> > > >  			/*
> > > >  			 * This is a silent loss of information.  We still
> > > >  			 * send the signal, but the *info bits are lost.
> > > >  			 */
> > > > -			trace_signal_lose_info(sig, group, info);
> > > > +			result = TRACE_SIGNAL_LOSE_INFO;
> > >
> > > Hmm, all this result manipulation added for tracing that doesn't occur
> > > in 99.99% of all machines?
> >
> > Not sure I understand...
>
> 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.



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 ;)

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

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/