linux-kernel - Re: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1321912356.20742.24.camel@frodo>
Date:	Mon, 21 Nov 2011 16:52:36 -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: Q: tracing: can we change trace_signal_generate() signature?

On Mon, 2011-11-21 at 21:21 +0100, Oleg Nesterov wrote:

> > > IOW. Ignoring the changes in include/trace/events/signal.h,
> > > can the patch below work or the changes like this are not
> > > allowed?
> >
> > I say change it and see who screams.
> 
> 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? ;)

> 
> > > +enum {
> > > +	TRACE_SIGNAL_DELIVERED,
> > > +	TRACE_SIGNAL_IGNORED_OR_BLOCKED,
> 
> (can't understand why I added _OR_BLOCKED, it should be
>  TRACE_SIGNAL_IGNORED)

quilt refresh?

> 
> > > @@ -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.

-- Steve

> 
> With this patch trace_signal_generate() also reports "result" which
> allows to know was the signal actually delivered or not. And, if not,
> why it wasn't delivered.
> 
> TRACE_SIGNAL_OVERFLOW_FAIL and TRACE_SIGNAL_LOSE_INFO are not really
> needed, but this way we can kill trace_signal_overflow_fail() and
> trace_signal_lose_info() and simplify the code.
> 
> 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/