Re: Can current macro be accessed from interrupt context?

[Clemens Ladisch <clemens@ladisch.de>]

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