Which context are softirq and tasklet in?

I know that there are process context and interrupt context but I don't understand when executing softirq or tasklet, which context is it run under.

I have seen some people use the term "bottom-halves context", if there's such term, what's the difference comparing with the others.

Another question to softirq and tasklet is that why sleep are not allowed during execution开发者_JAVA技巧??

Can anyone help me identify these questions, thanks!!

---

The softirq and tasklet are both kind of bottom-halves mechanism. Sleep is not allowed becuase they run under interrupt context not process context. If sleep is allowed, then the linux cannot schedule them and finally cause a kernel panic with a dequeue_task error. The interrupt context does not even have a data structure describing the register info, so they can never be scheduled by linux. If it is designed to have that structure and can be scheduled, the performance for interrupt handling process will be effected.

---

@kai: your qs reg which context bottom-halves execute in?

Technically, softirq's do run in an interrupt context - the "softirq" context; it's just that it's not "hard-irq" context (which is the context when a hardware interrupt occurs).

So, in a softirq handler, in terms of the 'lookup' macros Linux provides:

in_interrupt: yes | in_irq: no | in_softirq: yes | in_serving_softirq: yes

But be aware (beware!!! :): "all of the restrictions that apply to interrupt handlers also apply to bottom halves. Thus, bottom halves cannot sleep, cannot access user space, and cannot invoke the scheduler." -- LDD3.

Jermaine answers the rest of your question.

[Update] In addition, I'd like to point out that one can define simple and elegant macros that help print debug info as and when required. Over the years, I've put these macros and convenience routines into a header file; you can check it out and download it here: "A Header of Convenience".

There are macros / functions to:

• make debug prints along with funcname / line# info (via the usual printk() or trace_printk()) and only if DEBUG mode is On
  • dump the kernel-mode stack
  • print the current context (process or interrupt along with flags in the form that ftrace uses)
  • a simple assert() macro (!)
  • a cpu-intensive DELAY_LOOP (useful for test rigs that must spin on the processor)
  • an equivalent to usermode sleep functionality
  • a function to calculate the time delta given two timestamps (timeval structs)
  • convert decimal to binary, and
  • a few more.

Whew :-)

---

I agree with the accepted answer and Kaiwan's answer, but they did not mention ksoftirqd. If the CPU is under heavy load of softirqs and/or tasklets, it schedules its ksoftirqd thread which process the raised softirqs and tasklets in process context.

So I guess the answer to the OP's question would be: softirqs can run in either interrupt or process contexts.

Update: A quick look on run_ksoftirqd() shows that __do_softirq() is called with local irqs disabled. So, while technically running in process context, same restrictions (like no sleeping) apply.