title: About interrupt context,atomic context and process context in linux kernel
body: <p>As I know, we can verify that we are in interrupt context by involving <code>in_interrupt()</code> in linux kernel. And the implementation of the <code>in_interrupt()</code> function is counting by the <code>thread_info-&gt;preempt_count</code> when entering or exiting hardirq or softirq. So, when the <code>in_interrupt()</code> return none-zero, it indicates that we are processing in hardirq or softirq.</p>
  
  <p>However, My question is when we involve the <code>local_bh_disable()</code> function, it does increase the <code>thread_info-&gt;preempt_count</code>, so the <code>in_interrupt()</code> function return none-zero. Thus, how could we determine if we are in the interrupt context now. And in my opinion, atomic context is that local interrupt is disabled</p>
  
  <p>Here is a circumstances that I'm now in kernel mode, and I want to access the userland address space, but I don't know whether running in the process context or interrupt context, because of accessing userland address space in interrupt context is invalid, so I want to determine whether being in the process context by involving the <code>in_interrupt()</code> function. Then I got the return value greater than zero, thus, I will think that I am now in interrupt context and won't access the userland. However, maybe there are some function that imply involving the <code>local_bh_disable</code> to increase the <code>thread_info-&gt;preempt_count</code> to disable the sortirq, but in fact that, we are in process context and just disabling the softirq, thus, we could access the userland address space safely but we make a mistake.</p>