当前位置：首页 → 问答吧 → why vfree() must not be called in interrupt context?

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

时间：2009-08-07

来源：互联网

论坛里有人问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

作者: eexplorer 发布时间: 2009-08-07

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

作者: dreamice 发布时间: 2009-08-07

学习啦~

作者: kouu 发布时间: 2009-08-07

与重入有关吧

作者: nicozhou 发布时间: 2009-08-07

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

作者: emmoblin 发布时间: 2009-08-08

QUOTE:

原帖由 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 发布时间: 2009-08-08

QUOTE:

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

not sure why you got this conclusion?

作者: eexplorer 发布时间: 2009-08-08

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

作者: epegasus 发布时间: 2009-08-10

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

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

作者: epegasus 发布时间: 2009-08-10

QUOTE:

原帖由 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的话，就有可能引起死锁。

作者: eexplorer 发布时间: 2009-08-10

> 处理器间通信吗?
> 处理器通知其他处理器tlb flush.
> 为什么要等待其他处理器返回呢?这种通信机制是代码上看不到的呢?

CPU只是提供了这样一种机制，如何利用它是OS的事。on_each_cpu可以等待其他cpu完成，也可以不等待，这都是os实现的。

> 如果是,那么就是纯硬件实现了,那为什么硬件是没有考虑到这个锁的问题?
> 为什么又只有在关中断的情况下才出现这种死锁?

关了中断，那么这个cpu就收不到ipi了，这样两个cpu,每一个都disable了中断，而又在等待另一个cpu能收到ipi中断来完成tbl flush，有点像ab-ba deadlock (cpu1的中断资源为resource A, cpu2的中断资源为resource B).

[ 本帖最后由 eexplorer 于 2009-8-10 12:03 编辑 ]

作者: eexplorer 发布时间: 2009-08-10

学习了，都是大虾

作者: mingloie 发布时间: 2009-08-28

你是不是在国外的论坛都用中文留言呢？