Re: [RFC PATCH 10/11] mcount tracer show task comm and pid
* Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> static inline int vmalloc_fault(unsigned long address)
> {
> unsigned long pgd_paddr;
> pmd_t *pmd_k;
> pte_t *pte_k;
> /*
> * Synchronize this task's top level page-table
> * with the 'reference' page table.
> *
> >* Do _not_ use "current" here. We might be inside
> * an interrupt in the middle of a task switch..
> */
> pgd_paddr = read_cr3();
> pmd_k = vmalloc_sync_one(__va(pgd_paddr), address);
> if (!pmd_k)
> return -1;
> pte_k = pte_offset_kernel(pmd_k, address);
> if (!pte_present(*pte_k))
> return -1;
> return 0;
> }
>
> At context switch on x86, loading the registers is done first, and
> only after the is the current pointer set. However, for vmalloc
> faults, it's the value in the cr3 register that is important, which
> may not correspond to the cr3 value saved in "current".
>
> So, I think using the "pid" and "comm" fields of current, even in NMI
> context, is not a problem, just as you said. For early boot, the
> current task will be init_task, which has pid = 0 and comm =
> "swapper", still ok.
yeah - during the context-switch the value of 'current' might be 'stale'
in a number of ways, but it's always atomically and coherently either
pointing to the previous task or the next task. So from a tracing POV
it's perfectly safe to use it (and we've been doing that for ages with
the mcount stuff).
(The notrace mcount exclusions arent really to avoid any tracing
badness, they are mostly to make the trace less spammy and more
readable.)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 10/11] mcount tracer show task comm and pid
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > > @@ -34,6 +34,7 @@ mctracer_add_trace_entry(struct mctracer
> > > {
> > > unsigned long idx, idx_next;
> > > struct mctracer_entry *entry;
> > > + struct task_struct *tsk = current;
> >
> > Aren't there situations, like in the middle of a context switch, where
> > current is not valid ? Is also poses a problem for early boot, and NMI
> > tracing.
>
> no such problems on x86.
>
> Ingo
I based my comments on the following code snippet, but I think I start
to understand what makes it "so special"
arch/x86/mm/fault_32.c :
static inline int vmalloc_fault(unsigned long address)
{
unsigned long pgd_paddr;
pmd_t *pmd_k;
pte_t *pte_k;
/*
* Synchronize this task's top level page-table
* with the 'reference' page table.
*
>* Do _not_ use "current" here. We might be inside
* an interrupt in the middle of a task switch..
*/
pgd_paddr = read_cr3();
pmd_k = vmalloc_sync_one(__va(pgd_paddr), address);
if (!pmd_k)
return -1;
pte_k = pte_offset_kernel(pmd_k, address);
if (!pte_present(*pte_k))
return -1;
return 0;
}
At context switch on x86, loading the registers is done first, and only
after the is the current pointer set. However, for vmalloc faults, it's
the value in the cr3 register that is important, which may not
correspond to the cr3 value saved in "current".
So, I think using the "pid" and "comm" fields of current, even in NMI
context, is not a problem, just as you said. For early boot, the current
task will be init_task, which has pid = 0 and comm = "swapper", still
ok.
Thanks for pointing it out.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 10/11] mcount tracer show task comm and pid
* Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > @@ -34,6 +34,7 @@ mctracer_add_trace_entry(struct mctracer
> > {
> > unsigned long idx, idx_next;
> > struct mctracer_entry *entry;
> > + struct task_struct *tsk = current;
>
> Aren't there situations, like in the middle of a context switch, where
> current is not valid ? Is also poses a problem for early boot, and NMI
> tracing.
no such problems on x86.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 10/11] mcount tracer show task comm and pid
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> This adds the task comm and pid to the trace output. This gives the
> output like:
>
> CPU 0: sshd:2605 [] remove_wait_queue+0xc/0x4a <--
> [] free_poll_entry+0x1e/0x2a
> CPU 2: bash:2610 [] tty_check_change+0x9/0xb6 <--
> [] tty_ioctl+0x59f/0xcdd
> CPU 0: sshd:2605 [] _spin_lock_irqsave+0xe/0x81 <--
> [] remove_wait_queue+0x17/0x4a
> CPU 2: bash:2610 [] find_vpid+0x9/0x24 <--
> [] tty_ioctl+0x62f/0xcdd
> CPU 0: sshd:2605 [] _spin_unlock_irqrestore+0x9/0x3a <--
> [] remove_wait_queue+0x45/0x4a
> CPU 0: sshd:2605 [] fput+0x9/0x1b <-- []
> free_poll_entry+0x26/0x2a
>
>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> ---
> lib/mcount/tracer.c |6 +-
> lib/mcount/tracer.h |3 +++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> Index: linux-compile.git/lib/mcount/tracer.c
> ===
> --- linux-compile.git.orig/lib/mcount/tracer.c2008-01-02
> 23:17:21.0 -0500
> +++ linux-compile.git/lib/mcount/tracer.c 2008-01-02 23:17:44.0
> -0500
> @@ -34,6 +34,7 @@ mctracer_add_trace_entry(struct mctracer
> {
> unsigned long idx, idx_next;
> struct mctracer_entry *entry;
> + struct task_struct *tsk = current;
Aren't there situations, like in the middle of a context switch, where
current is not valid ? Is also poses a problem for early boot, and NMI
tracing.
>
> idx = tr->trace_idx[cpu];
> idx_next = idx + 1;
> @@ -52,6 +53,8 @@ mctracer_add_trace_entry(struct mctracer
> entry->idx = atomic_inc_return(&tr->cnt);
> entry->ip= ip;
> entry->parent_ip = parent_ip;
> + entry->pid = tsk->pid;
> + memcpy(entry->comm, tsk->comm, TASK_COMM_LEN);
> }
>
> static inline notrace void trace_function(const unsigned long ip,
> @@ -223,7 +226,8 @@ static int s_show(struct seq_file *m, vo
> return -1;
> }
>
> - seq_printf(m, " CPU %d: ", iter->cpu);
> + seq_printf(m, "CPU %d: ", iter->cpu);
> + seq_printf(m, "%s:%d ", iter->ent->comm, iter->ent->pid);
> seq_print_ip_sym(m, iter->ent->ip);
> if (iter->ent->parent_ip) {
> seq_printf(m, " <-- ");
> Index: linux-compile.git/lib/mcount/tracer.h
> ===
> --- linux-compile.git.orig/lib/mcount/tracer.h2008-01-02
> 23:16:15.0 -0500
> +++ linux-compile.git/lib/mcount/tracer.h 2008-01-02 23:17:44.0
> -0500
> @@ -2,11 +2,14 @@
> #define _LINUX_MCOUNT_TRACER_H
>
> #include
> +#include
>
> struct mctracer_entry {
> unsigned long idx;
> unsigned long ip;
> unsigned long parent_ip;
> + char comm[TASK_COMM_LEN];
> + pid_t pid;
> };
>
> struct mctracer_trace {
>
> --
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
