From: Wengang <wen.gang.wang@oracle.com>
To: linux-kernel@vger.kernel.org
Cc: Wengang Wang <wen.gang.wang@oracle.com>,
Santosh Shilimkar <santosh.shilimkar@oracle.com>,
Srinivas Eeda <srinivas.eeda@oracle.com>
Subject: tasklet_kill makes sure no future re-schedule?
Date: Thu, 28 Jul 2016 12:52:17 -0700 [thread overview]
Message-ID: <01b3cc9a-2563-e31a-12b2-9f80924e71ce@oracle.com> (raw)
Hi,
I recently hit an issue that after tasklet_kill called against a tasket,
the tasklet can still be scheduled in IRQ context and run at a later time.
So my question is whether tasklet_kill is designed to make sure no
future re-scheduling can be done. I didn't find an official document
stating that, but find some non-official ones. The thing is that the
voices are different:
Someone (http://www.makelinux.net/books/lkd2/ch07lev1sec3) says
"You can remove a tasklet from the pending queue via tasklet_kill().
This function receives a pointer as a lone argument to the tasklet's
tasklet_struct. Removing a scheduled tasklet from the queue is useful
when dealing with a tasklet that often reschedules itself. This function
first waits for the tasklet to finish executing and then it removes the
tasklet from the queue. Nothing stops some other code from rescheduling
the tasklet, of course. This function must not be used from interrupt
context because it sleeps."
And someone else (http://www.makelinux.net/ldd3/chp-7-sect-5) says
"This function ensures that the tasklet is not scheduled to run again;
it is usually called when a device is being closed or the module
removed. If the tasklet is scheduled to run, the function waits until it
has executed. If the tasklet reschedules itself, you must prevent it
from rescheduling itself before calling tasklet_kill, as with
del_timer_sync."
Looking at the code, I prefer "Nothing stops some other code from
rescheduling the lasklet". But I want a confirm here please!
Thanks,
Wengang
reply other threads:[~2016-07-28 19:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=01b3cc9a-2563-e31a-12b2-9f80924e71ce@oracle.com \
--to=wen.gang.wang@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=santosh.shilimkar@oracle.com \
--cc=srinivas.eeda@oracle.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
all inboxes | Powered by JetHome®