sti は誰が

ひらたさんから頂いたコメントに激しく動揺。kernel/spinlock.c とか include/linux/spinlock.h とかその他モロモロを追いかけまくる。
駄目ぢゃ、分かんねぇ、と言いつつ arch/i386/kernel/entry.S から do_IRQ()#arch/i386/kernel/irq.c とかそれ以降も見た。ワケワカ。sti の発行 (local_irq_enable マクロにおいて処理が定義されている) を行なっていないように見受けられる。
ちなみに頂いたコメントを以下に引用しておきます。

local_irq_restore()では、local_irq_save()する前の割り込み状態を復元するのが目的なので、stiしてはだめなのです。
cli発行する前が、すでに割り込み禁止状態になっているかもしれないので、stiしてしまうと、割り込み許可状態になってしまいますね。
ひらたさんから頂いたコメントより引用
ちょっと探してみないとナニなんですが、sti な命令を発行しているのは local_irq_enable マクロ (include/i386/system.h) のみ?? TAG の逆引き (呼出し元の特定) ってデキンのかー!? (いや、デキるかも)

で、ちょっと読学のススメ方面にお伺いを立ててみると、2.4 では spin_unlock_irq() から sti を発行している local_irq_enable() が呼び出されていて、これ (spin_unlock_irq) を呼び出してるのは schedule()#kernel/sched.c のみ、との事。むむむ。

なんとなく解が見えたようなカンジなんですが、もう少しきっちり調べる必要あり。

追記

同期と排他、だけでなく割り込みな部分も中途半端なコトに気がつく。なんつーかムサボリ食ってる感満載ッス。(とほほほ

追記 2

む。ちらっと見てみたんですが、結構複雑やっさ。> sched.c
ただ、割り込みな処理が終わったら、以降の始末はスケジューラがナニ、って事で良いのかなぁ。ま、その内分かるっしょ。(を