Why can not processes switch in atomic context?

[anish singh]

Always CC Kernelnewbies.

On Wed, Jul 4, 2012 at 12:52 AM, Parmenides <mobile.parmenides at gmail.com> wrote:
>>> 1. For the spinlock case, it is easy to get if preemption is allowed
>>> in critical section, the purpose of protection provided by spinlock
>>> can not be achieved readily.
>> I don't know what you mean here.Please clarify.
>>>
>
> Sorry, this is not a problem really. :-)  A critical section protected
> by a spinlock is atomic. So, preemption is prohibited when kernel
> enter this kind of critical section. I just want make sure it is the
> case.
>
>
>>> 2. For the interrupt context case, I think when processing interrupt,
>>> kernel can be preempted in principle. But, this really increases the
>>> interrupt processing time which further cause longer response time and
>>> data missing in device. Except that, is there any other reasons?
>> data missing in device.Can you elaborate that?
>> Stack space is pretty limited in ISR context.Does that give you a clue?
>>>
>
> data missing: For example, if a interrupt sent by Ether card can not
> processed for a long time, some frames received from the cable might
> be discarded owing to its limit buffer on card.
> Actually, every process has its kernel stack. If a preemption occurs
> during interrupt processing, the stack of another process is used. So,
> I think stack space is not a problem at all.
https://lkml.org/lkml/2007/8/3/2 this thinks otherwise.Please read this as
stack space is one of the reasons why sleeping is not allowed in ISR context.
>
>
>>> 3. Kernel is responsible for prohibiiting passive process switches,
>>> namely preemption, in the above cases. But, It seems that it does not
>>> take care of active process swtiches, namely yield. For example, some
>>> code in a critical section protected by a spinlock can invoke
>>> schedule() to switch process passively. Is this the case?
>> I don't understand this question but we don't switch when we are holding
>> spinlock as that will jeopardize the integrity of the system i.e.
>> suppose you slept while holding spinlock.What would happen?
>
> So, kernel maintains its integrity relying on that we don't yield
> while in interrupt handler or critical section protected by a
> spinlock. If we do so, kernel do nothing at all. Why doesn't it refuse
> schedule when it finds out that we yield in a improper context.
AFAIK it prints some kind of warning message.Why don't you try this?
Call schedule in ISR context(try in threaded ISR) and share with us the results.