shedule()

Ответ - можно, if (!in_atomic ())

Потому что прерывание может произойти, когда исполняется код в ядре внутри пары preempt_disable/preempt_enable, а в этом случае schedule вызывать нельзя

> Ответ - можно, if (!in_atomic ())

нет, никогда нельзя.

не говоря о том уже, что что in_atomic() в interrupt
context всегда должен быть true (исключение - некоторые
smp_xxx_interrupt функции, напр. smp_reschedule_interrupt()
) которые не делают irq_enter/irq_exit.

Если контекстом прерывания называть строго код обработчика, устанавливаемого по request_irq, то да, согласен. А в самом общем случае - !in_atomic ()

> Потому что прерывание может произойти, когда исполняется
> код в ядре внутри пары preempt_disable/preempt_enable,

это тоже не совсем верно.

нельзя потому, что у нас просто нет process context'a
для schedule.

i386 _может_ пользоваться current and friends в контексте
прерывания, но это - особенность реализации.

> Если контекстом прерывания называть строго код обработчика,
> устанавливаемого по request_irq

не только. softirq, например.

про in_atomic() лучше вообще не вспоминать. если
!CONFIG_PREEMPT то после spin_lock() он == 0, это
вовсе не значит, что можно делать schedule().

огромное спасибо всем откликнувшимся.просветился :)

> i386 _может_ пользоваться current and friends в контексте > прерывания, но это - особенность реализации.

> про in_atomic() лучше вообще не вспоминать. если > !CONFIG_PREEMPT то после spin_lock() он == 0, это > вовсе не значит, что можно делать schedule().

мм. похоже, что ты прав.. картина складывается