lkml.org 
[lkml]   [2011]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Q: tracing: can we change trace_signal_generate() signature?
    From
    Date
    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.




    \
     
     \ /
      Last update: 2011-11-21 22:55    [W:0.022 / U:65.728 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site