0

I am using the following API to kill a tasklet:

tasklet_kill();

While killing the tasklet, I have disabled local interrupts using spin_lock_irqsave. Why does the kernel throws the following message(warning?):

Attempt to kill tasklet from interrupt

Is it not advisable to use tasklet_kill() while holding a spin_lock?

Santosh A
  • 5,173
  • 27
  • 37
Neelansh Mittal
  • 37
  • 4
  • I don't know the actual reason of the message (it is actually [notice](http://elixir.free-electrons.com/linux/v4.13.3/source/kernel/softirq.c#L585), not a warning). But if the tasklet is run (on other CPU), the function is intended to **wait** until it completes. Given wait is actually a *busy wait*, that is it is allowed with interrupts disabled. But are you sure that you want to **wait** a task, which you have specially moved into tasklet, with interrupts disabled? – Tsyvarev Sep 26 '17 at 16:50
  • Yes.I want any pending tasklets(already scheduled) to get completed. Also i want that no new tasklets to get scheduled, hence need to disable interrupts to ensure that no new tasklet is scheduled from the interrupt handler – Neelansh Mittal Sep 29 '17 at 06:29

1 Answers1

0

if you take a look at the func itself you will find it has a call to yield, which can give up the cpu. but that's prohibited with interrupts disabled and/or a spin lock held.

  • Are you sure that calling `yield()` is **prohibited** with interrupts disabled? While this function calls `schedule()` internally, it does that with `set_current_state(TASK_RUNNING);`, that is **without changing thread's state**. As far as I understand, with disabled interrupts `yield` never give up the cpu, it is simply no-op. – Tsyvarev Sep 29 '17 at 07:52
  • it calls sys_sched_yield, as if it was userspace doing it –  Sep 30 '17 at 08:44
  • I have already noticed that syscall. But again, I know no general rule that syscalls cannot be called with interrupts disabled. (However, direct syscalls from the Linux kernel tends to be avoided). – Tsyvarev Sep 30 '17 at 08:48
  • there is no rule against "any" syscall, but syscalls are entry points and calling them like this is a layering violation. a toy syscall may work, but you can't expect regular ones to behave like this. as for this syscall in particular, you can easily check it starts with disabling interrupts. (and not in an _irqsave manner) and then tries to put the thread off cpu. in short, yield is not safe to be called with irqs disabled. –  Sep 30 '17 at 08:51
  • Ok, may be calling `lockal_irq_disable()` implies that function shouldn't be called with disabled interrupts. However, it looks suspicious that message is just a *notice*, not a *warning* or an *error*. – Tsyvarev Sep 30 '17 at 09:16