why vfree() must not be called in interrupt context?

eexplorer

论坛里有人问vfree(): sleeping in interrupt!!的问题，看了一下vfree的code, 没有发现vfree里有引起sleep的code,想了半天+google也没有发现什么有价值的信息。找到的几个帖子，都是说vfree不能在interrupt context里调用，但是都没有说明为什么？

最后去Linux Kernel Newbies的irc channel(irc.oftc.net #kernelnewbies)去问了一下，有个叫peterz的id回答了我的问题：

Q: Why vfree must not be called in interrupt context?

A: the tlb flushing can deadlock with IRQs disabled as it relies on IPIs

suppose two cpus are in interrupt context (with interrupts disabled),
both then want to vfree which would result in a TLB flush, the TLB flush
will IPI the other cpu to clear its TLB, but the other CPU has interrupts
disabled so both keep waiting for the other to process the TLB flush -> deadlock


btw, 我怀疑peterz就是大牛Peter Zijlstra

dreamice

vfree可能直接调用睡眠函数，中断中是不允许睡眠的

kouu

学习啦~

nicozhou

与重入有关吧

emmoblin

vfree对应的时vmalloc，分配的可能是不连续的内存空间。
可能导致睡眠

eexplorer

原帖由 dreamice 于 2009-8-7 20:00 发表
vfree可能直接调用睡眠函数，中断中是不允许睡眠的

I've already said in my post, that I haven't found any code in vfree() than will make it sleep. If you find any,  please point out!

eexplorer

原帖由 emmoblin 于 2009-8-8 01:08 发表
vfree对应的时vmalloc，分配的可能是不连续的内存空间。
可能导致睡眠

not sure why you got this conclusion?

epegasus

IPIs是什么,没听过...
意思是多处理器中发生死锁?

epegasus

处理器间通信吗?
处理器通知其他处理器tlb flush.
为什么要等待其他处理器返回呢?这种通信机制是代码上看不到的呢?
如果是,那么就是纯硬件实现了,那为什么硬件是没有考虑到这个锁的问题?
为什么又只有在关中断的情况下才出现这种死锁?

[ 本帖最后由 epegasus 于 2009-8-10 11:50 编辑 ]

eexplorer

原帖由 epegasus 于 2009-8-10 11:14 发表
IPIs是什么,没听过...
意思是多处理器中发生死锁?

在x86的smp环境下，一个processor可以通过他自己的local apic向其他的cpu 发送interrupt (inter-processor interrupt)。

如果需要在每个cpu上flush tlb的话，就需要用到ipi了。

void flush_tlb_all(void)
{
        on_each_cpu(do_flush_tlb_all, NULL, 1);
}

在vfree这个case里，一旦两个cpu都disalbe了IRQ再去flush tlb的话，就有可能引起死锁。