From: Juergen Quade <quade@hsnr.de>
To: Nagendra Singh Tomar <nagendra_tomar@adaptec.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: tasklet_kill will always hang for recursive tasklets on a UP
Date: Wed, 27 Aug 2003 20:21:49 +0200 [thread overview]
Message-ID: <20030827182149.GA23439@hsnr.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0308252233480.31393-100000@localhost.localdomain>
> Thanx for ur inputs. I think that I am missing something in ur
> explanation. Can u please elaborate. In the meantime, the approach that I
Maybe it is easier we make it the other way round.
If you look at the code of tasklet_kill:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk("Attempt to kill tasklet from interrupt\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) {
do
yield();
while (test_bit(TASKLET_STATE_SCHED, &t->state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, &t->state);
}
Can you explain me, what the last statement
clear_bit(TASKLET_STATE_SCHED, &t->state);
is for?
> will like is to have another state TASKLET_STATE_KILLED so the code
> changes that need to be done are
>
> void tasklet_kill(struct tasklet_struct *t)
> {
>
> ...
> ...
> /*
> * Mark the tasklet as killed, so the next time around
> * tasklet_action does not call the handler for this tasklet
> */
> set_bit(TASKLET_STATE_KILLED, &t->state); <-- ADDED
> ...
>
What I don't like on this approach is, to add another flag (=state) to
the tasklet, which might make the world more complicated as necessary.
I will take some time to think about it, but can't do that today :-(
Beside this, if you can't use a function without looking
at the code and without experimenting with it, that
must lead to bugs! IMHO, here is a call for action.
Juergen.
next prev parent reply other threads:[~2003-08-27 18:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-25 0:00 tasklet_kill will always hang for recursive tasklets on a UP Nagendra Singh Tomar
2003-08-25 1:53 ` Nagendra Singh Tomar
2003-08-25 14:11 ` Juergen Quade
2003-08-25 17:14 ` Nagendra Singh Tomar
2003-08-27 18:21 ` Juergen Quade [this message]
2003-08-27 17:46 ` Nagendra Singh Tomar
2003-08-28 15:29 ` Juergen Quade
2003-08-28 15:53 ` kuznet
2003-08-28 16:17 ` Juergen Quade
2003-08-29 2:22 ` Werner Almesberger
2003-08-26 5:48 ` Werner Almesberger
2003-08-25 18:45 ` Nagendra Singh Tomar
2003-08-26 7:38 ` Werner Almesberger
2003-08-26 8:32 ` Juergen Quade
2003-08-26 17:56 ` Werner Almesberger
2003-08-27 1:47 ` kuznet
2003-08-26 16:17 ` Nagendra Singh Tomar
2003-08-28 13:17 ` kuznet
2003-08-28 16:25 ` Nagendra Singh Tomar
2003-09-04 13:25 ` kuznet
2003-08-29 2:30 ` Werner Almesberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030827182149.GA23439@hsnr.de \
--to=quade@hsnr.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nagendra_tomar@adaptec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox