Can current macro be accessed from interrupt context?

Can current macro be accessed from interrupt context?

[Leonidas .]

Hello,

Going through UTLK, it says that current macro makes sense only in
case of process context,
in case of interrupt context it is invalid.

But current would still be pointing to interrupted process right? The
pointer would still be valid?
Can I safely assume that whether or not interrupt handlers are
executing on separate stacks or
interrupted threads stack, current macro can be accessed from interrupt context?

My use case is to get process id from any context with CONFIG_4KSTACKS = 0 or 1.

Any pointers will be helpful.
-Leo.

Re: Can current macro be accessed from interrupt context?

[Frederic Weisbecker]

On Thu, Oct 22, 2009 at 04:10:49AM -0700, Leonidas . wrote:
> Hello,
> 
> Going through UTLK, it says that current macro makes sense only in
> case of process context,
> in case of interrupt context it is invalid.


Indeed, usually it makes only sense in process context.

 
> But current would still be pointing to interrupted process right? The
> pointer would still be valid?



Yeah, unless you irq handler executes in a threaded interrupt, in
which case current will be pointing to the given irq thread.

There are few tiny cases where it is unsafe to deref "current",
such as the very beginning of a cpu's awakening, when the per cpu
datas are not yet ready for this cpu.


> Can I safely assume that whether or not interrupt handlers are
> executing on separate stacks or
> interrupted threads stack, current macro can be accessed from interrupt context?


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.

Frederic.

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

On Thu, Oct 22, 2009 at 4:27 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 04:10:49AM -0700, Leonidas . wrote:
>> Hello,
>>
>> Going through UTLK, it says that current macro makes sense only in
>> case of process context,
>> in case of interrupt context it is invalid.
>
>
> Indeed, usually it makes only sense in process context.
>
>
>> But current would still be pointing to interrupted process right? The
>> pointer would still be valid?
>
>
>
> Yeah, unless you irq handler executes in a threaded interrupt, in
> which case current will be pointing to the given irq thread.

Threaded interrupt handlers? I am sorry, I am new to kernel development
and not fully aware of the intricacies. Do you mean bottom half handlers here?

> There are few tiny cases where it is unsafe to deref "current",
> such as the very beginning of a cpu's awakening, when the per cpu
> datas are not yet ready for this cpu.
>

Okay, I guess, in my case this would not be a problem then since this is about
early init.

>> Can I safely assume that whether or not interrupt handlers are
>> executing on separate stacks or
>> interrupted threads stack, current macro can be accessed from interrupt context?
>
>
> 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?

> Frederic.
>
>


-Leo.

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

Got

http://lwn.net/Articles/324980/

explains threaded interrupt handlers, please dont bother to spend time
on explaining, my bad, I should have
searched before replying.

Thanks.
-Leo

Re: Can current macro be accessed from interrupt context?

[Frederic Weisbecker]

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.

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

Thanks for your explanation, this solves my problem.

-Leo.

Re: Can current macro be accessed from interrupt context?

[Arjan van de Ven]

On Thu, 22 Oct 2009 04:10:49 -0700
"Leonidas ." <leonidas137@gmail.com> wrote:

> Hello,
> 
> Going through UTLK, it says that current macro makes sense only in
> case of process context,
> in case of interrupt context it is invalid.
> 
> But current would still be pointing to interrupted process right? The
> pointer would still be valid?
> Can I safely assume that whether or not interrupt handlers are
> executing on separate stacks or
> interrupted threads stack, current macro can be accessed from
> interrupt context?

not for interrupt threads, and that's where things are moving to.

for interrupt stacks you ought to be fine (current is just a pointer on
the stack, and last I looked we copied that pointer for each interrupt
to the irq stack)

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Can current macro be accessed from interrupt context?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Thu, 22 Oct 2009 04:10:49 PDT, "Leonidas ." said:

> My use case is to get process id from any context with CONFIG_4KSTACKS = 0 or 1.

You *do* realize that if you're in interrupt context, the value of 'current'
probably has absolutely nothing to do with the interrupt?  The process/thread
that is responsible for an I/O interrupt is probably in a blocked state waiting
for the I/O to complete, and the *running* process is often some other process.
And for some interrupts (timer, etc), all bets are off...

So given that the process ID is quite often totally pointless, what were you
trying to accomplish by getting the process ID?

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

>
> So given that the process ID is quite often totally pointless, what were you
> trying to accomplish by getting the process ID?
>

I am glad that you asked this question. Actually, what I am trying to
do may not be
even feasible in kernel space. Just spending some cycles on checking
the feasibility.

Here is what I am trying to do.

I am trying to emulate thread local storage in kernel space. Only conceptually.
In user space, multithreaded programs can avoid locking issues by keeping
per thread data structures, as per my understanding in kernel space there is
no such notion. Per cpu data structures is not quite the same thing
since locking
can be avoided only for accessing data local to that cpu, for
accessing data belonging
to other cpus, we would still need some locking mechanism.

Assume that, a multithreaded app talks to my kernel module using
/dev/node, and I need
to book keep certain data in kernel module. The data I am book keeping
can be kept in a
central data structure protected by spinlocks. A better way would be
per cpu data structure.

My idea is to keep data specific to each task which is talking to my
kernel module. Assumption
here is a certain task can be in kernel mode only on one cpu at a time
hence that task specific
data structure can be accessed without locks. All book keeping which
needs to be done in ISRs
would be just book keeping for the interrupted task, i.e. we would
populate interrupted task's
data structure. This is where current comes in picture.

-Leo.

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

Assumption
> here is a certain task can be in kernel mode only on one cpu at a time
> hence that task specific
> data structure can be accessed without locks.

This is pretty much like per cpu variables, right? Conceptually there
is no difference
in per-cpu mechanism and what I am thinking.

-Leo.

Re: Can current macro be accessed from interrupt context?

[Clemens Ladisch]

Leonidas . wrote:
> I am trying to emulate thread local storage in kernel space.  [...]
> Assume that, a multithreaded app talks to my kernel module using
> /dev/node, and I need to book keep certain data in kernel module. The
> data I am book keeping can be kept in a central data structure
> protected by spinlocks. A better way would be per cpu data structure.
> 
> My idea is to keep data specific to each task which is talking to my
> kernel module. Assumption here is a certain task can be in kernel mode
> only on one cpu at a time hence that task specific data structure can
> be accessed without locks.

There is no fixed association between your tasks and the CPUs they are
running on.  It is possible for two of your threads to be executed on
the same CPU (one after the other), or for one thread to migrate between
CPUs.

> All book keeping which needs to be done in ISRs would be just book
> keeping for the interrupted task, i.e. we would populate interrupted
> task's data structure. This is where current comes in picture.

The task that was interrupted is probably some entirely different task
(the X server, the shell, your mail reader, some kernel thread, or
any of the other tasks running on your system).

It is possible for your interrupt handler to be called for some device
request that belongs to one of your tasks that is currently running on
another CPU, so you won't be able to manage that data without locking.


Best regards,
Clemens

Re: Can current macro be accessed from interrupt context?

[Leonidas .]

> There is no fixed association between your tasks and the CPUs they are
> running on.  It is possible for two of your threads to be executed on
> the same CPU (one after the other), or for one thread to migrate between
> CPUs.

Yes, you are right. I had not thought about thread migration etc and was
painting a rather simple picture of things.

>
> The task that was interrupted is probably some entirely different task
> (the X server, the shell, your mail reader, some kernel thread, or
> any of the other tasks running on your system).
>
> It is possible for your interrupt handler to be called for some device
> request that belongs to one of your tasks that is currently running on
> another CPU, so you won't be able to manage that data without locking.
>

Yes, this is pretty much points towards using per-cpu data.
Seems like my thought experiment will lead to an early demise.

Thanks for the explanation.


-Leo.