| Linux Forum Index » Linux Development - System » interrupt context & current... |
|
Page 1 of 1 |
|
| Author |
Message |
| maciek borzecki... |
 Posted: Wed Sep 16, 2009 11:25 pm |
|
|
|
Guest
|
Hi,
I'm working on an XScale based platfrom with 2.6.18-rt5 kernel and
there is a strange issue with interrupts going on which I need to
debug.
In the interrupt context, it is possible to access current? I'd like
to know which task was preempted when the IRQ line was raised.
BTW. is that thrue that the thread_info is always at the beginning of
stack? so that thread_info * = stack - sizeof(struct thread_info)?
Thanks,
maciek |
|
|
| Back to top |
|
|
|
| zix... |
| Posted: Thu Sep 17, 2009 1:24 am |
|
|
|
Guest
|
Quote: In the interrupt context, it is possible to access current?
Interrupt does not run in anybody's context, so u cant access current |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Fri Sep 25, 2009 1:50 am |
|
|
|
Guest
|
On Sep 17, 2:25 am, maciek borzecki <maciek.borze... at (no spam) gmail.com> wrote:
Quote: In the interrupt context, it is possible to access current? I'd like
to know which task was preempted when the IRQ line was raised.
No, it is not possible, and attempts to do so will lead only to pain.
The problem is that the context that was interrupted can be in any
state at all, consistent or inconsistent. It may hold interruptible
locks, it may not.
DS |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Fri Sep 25, 2009 7:38 am |
|
|
|
Guest
|
On Sep 25, 7:52 am, Chris Friesen <cbf... at (no spam) mail.usask.ca> wrote:
Quote: How can it cause problems to make a copy of current->pid from an
interrupt handler?
Suppose the code interrupted looks like this:
acquire_some_lock();
current->pid++;
// interrupt occurs here
current->pid--;
release_some_lock();
Or even:
acquire_some_lock();
saved_context=current;
current=create_special_context();
release_some_lock();
do_work_in_special_context();
acquire_some_lock();
destroy_context(current);
// interrupt occurs here
current=saved_context;
release_some_lock();
Now dereferencing 'current' accesses an invalid pointer.
DS |
|
|
| Back to top |
|
|
|
| Chris Friesen... |
| Posted: Fri Sep 25, 2009 8:52 am |
|
|
|
Guest
|
On 09/25/2009 05:50 AM, David Schwartz wrote:
Quote: On Sep 17, 2:25 am, maciek borzecki <maciek.borze... at (no spam) gmail.com> wrote:
In the interrupt context, it is possible to access current? I'd like
to know which task was preempted when the IRQ line was raised.
No, it is not possible, and attempts to do so will lead only to pain.
The problem is that the context that was interrupted can be in any
state at all, consistent or inconsistent. It may hold interruptible
locks, it may not.
How can it cause problems to make a copy of current->pid from an
interrupt handler?
Chris |
|
|
| Back to top |
|
|
|
| Chris Friesen... |
| Posted: Fri Sep 25, 2009 2:54 pm |
|
|
|
Guest
|
On 09/25/2009 11:38 AM, David Schwartz wrote:
Quote: On Sep 25, 7:52 am, Chris Friesen <cbf... at (no spam) mail.usask.ca> wrote:
How can it cause problems to make a copy of current->pid from an
interrupt handler?
Suppose the code interrupted looks like this:
acquire_some_lock();
current->pid++;
// interrupt occurs here
current->pid--;
release_some_lock();
Within the kernel current->pid only ever changes when calling fork().
So the worst case is that there's a small window where you could get the
parent's pid instead of the child.
Quote: Or even:
acquire_some_lock();
saved_context=current;
current=create_special_context();
release_some_lock();
do_work_in_special_context();
acquire_some_lock();
destroy_context(current);
// interrupt occurs here
current=saved_context;
release_some_lock();
Now dereferencing 'current' accesses an invalid pointer.
It doesn't work that way. Within the kernel, "current" is a special
global variable that only ever changes when context-switching from one
schedulable thread to another. Interrupts are generally processed on
their own stack, but "current" still points to the task struct of the
task that was interrupted.
Chris |
|
|
| Back to top |
|
|
|
| Phil Carmody... |
| Posted: Sat Sep 26, 2009 2:36 am |
|
|
|
Guest
|
David Schwartz <davids at (no spam) webmaster.com> writes:
Quote: On Sep 25, 7:52Â am, Chris Friesen <cbf... at (no spam) mail.usask.ca> wrote:
How can it cause problems to make a copy of current->pid from an
interrupt handler?
Suppose the code interrupted looks like this:
acquire_some_lock();
current->pid++;
Surely "Don't do something dumb" should be stressed more than "don't
do something dumb because others may be doing things even more dumb"?
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1 |
|
|
| Back to top |
|
|
|
|
