linux-kernel - Re: Can current macro be accessed from interrupt context?

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: <20091022120613.GB4928@nowhere>
Date:	Thu, 22 Oct 2009 14:06:17 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Leonidas ." <leonidas137@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Can current macro be accessed from interrupt context?

On Thu, Oct 22, 2009 at 04:43:38AM -0700, Leonidas . wrote:
> > Yep.
> > For example we do that in the function graph tracer. Because we store return
> > addresses of functions in the "current" task structure. Even if the task
> > is interrupted, it still makes sense to use current because we want
> > to know the flow of execution as a linear thing per cpu, the interrupt
> > is part of that flow
> >
> > I hope that helps.
> >
> 
> Can you give pointers to the source code of this project?

Yep, it's in kernel/trace/trace_functions_graph.c (with a little
part in arch/*/kernel/ftrace.c and arch/*/kernel/entry*.S)
and also parts in kernel/trace/ftrace.c

We do that from the former file in ftrace_push_return_trace()
and ftrace_pop_return_trace()

We deref current from whatever context, this part of the code doesn't care
about interrupt or process context, and this code can be called from
every contexts, since it is tracing 99% of the kernel function calls.

We do care about the context in which the trace has been taken while displaying
these traces to the user, later, just to inform the user, but this is already 
post-processing at this stage, even though it's done from the kernel.

Anyway, the point is that it's safe to deref current from an irq handler.

But whether it makes sense to do that. It depends on what you want to do.

--
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/