linux-kernel - Re: [PATCH 0/3] tracing/function-graph-tracer: signal interrupt triggering on output

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: <c62985530812130626m75fea357wa24499bc72e63609@mail.gmail.com>
Date:	Sat, 13 Dec 2008 15:26:01 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] tracing/function-graph-tracer: signal interrupt triggering on output

2008/12/13 Ingo Molnar <mingo@...e.hu>:
> that reminds me ... did you know about hardirq_count()? We could use it
> to detect IRQ entries in a more generic way, instead of the section
> trick?


No I didn't know it but thought about it indirectly.
This counter is inc/dec on irq_enter and irq_exit. I wanted first to
send some special events
while entering irq_enter/exit to notice interrupt events. The problem
is that the irq is raised a bit sooner.
If I used I would have:

    foo() {
        smp_apic_timer_interrupt() {
            irq_enter() {
                 ===> //hardirq_count() is incremented here
            }
        }
    }

We would loose so the sense of the arrow here. Its role is to explain
the breakage into
the code flow by the interrupt. The role of the arrow is to explain
that smp_apic_timer_interrupt is not called
by foo().

One thing I would suggest would be to move these irq_enter/exit on entry_xx.S

> Another thing, i just noticed that ftrace_print() is broken in certain
> situations, for example a plain newline:
>
>        ftrace_printk("\n");
>
> printed via trace_pipe will print some weirdly concatenated line:
>
>           <...>-2994  [007]   406.498986: debug_show:          <...>-2994  [007]   406.498986:            <...>-2994  [007]   406.498986: debug_show:
>
> not via a separate, standalone, empty line.

Ok, I will send a patch.

>
> Another thing: it would be nice to have a trace_option to leave out this
> preamble:
>
>           <...>-2994  [007]   406.498986: debug_show:  test printk
>
> and just give this output:
>
>  test printk
>
> i.e. some 'printk compatibility' mode. That way i could use
> ftrace_printk() as a pure replacement for printk, during development.
>
>        Ingo
>

Ok. I will add a flag for that too.
--
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/