模块卸载时如何避免race condition？

netentsec

拿ip_conntrack为例，
在流量非常大的时候，cat /proc/net/ip_conntrack需要很长的时间，
如果cat返回之前，如果执行rmmod ip_conntrack会不会有问题？

以2.6.15为例，ip_conntrack_standalone.c 的简化框架见后。

问题是

1）在cat /proc/net/ip_conntrack的过程中，如果执行rmmod ip_conntrack，
[2]会不会失败？ 特别的会不会出现
    remove_proc_entry: xxx busy, count=1;
    de_put: deferred delete of xxx
类似的消息？
如果没有，那是如何保证没有问题的？
跟[1]（synchronize_rcu）有没有关系？

2）如果[2]失败，[5]处会free掉ip_conntrack的空间，
但是造成[2]失败的cat进程并不知道空间被释放了，继续访问就会有问题。

3）与前面的问题类似，如果模块本身是个target或者match，
在规则加载的时候（checkentry）创建proc文件，
在规则卸载的时候（destory）删除proc文件，
proc文件引用了动态分配的空间（该空间在destory中被释放）。

如果访问proc文件跟规则卸载同步进行，是否也会出现remove_proc_entry失败的情况？
在这种情况下，应采取什么手段来保证remove_proc_entry一定成功呢？
或者说如何保证对proc文件的访问不会引用被释放的空间？
有没有已有的模块处理类似的问题？

static void __exit fini(void)
{
    init_or_cleanup(0);
}

static int init_or_cleanup(int init)
{
    if (!init) goto cleanup;
    ......
cleanup:
    synchronize_net();    //[1]
    .......
cleanup_proc:
    proc_net_remove("ip_conntrack");   //[2]
    ......
cleanup_init:
    ip_conntrack_cleanup();
    .......
}

void ip_conntrack_cleanup(void)
{
    ......
    synchronize_net();    //[3]
    ......
i_see_dead_people:    //[4]
    ip_conntrack_flush();
    if (atomic_read(&ip_conntrack_count) != 0) {
        schedule();
        goto i_see_dead_people;
    }
    .......
   free_conntrack_hash(ip_conntrack_hash, ip_conntrack_vmalloc, ip_conntrack_htable_size);    //[5]
   ......
}

static void *ct_seq_start(struct seq_file *seq, loff_t *pos)
{
   read_lock_bh(&ip_conntrack_lock);    //[6]
   return ct_get_idx(seq, *pos);
}

static void ct_seq_stop(struct seq_file *s, void *v)
{
   read_unlock_bh(&ip_conntrack_lock);    //[7]
}

baohuaihuai

肯定会出现
remove_proc_entry: xxx busy, count=1;
de_put: deferred delete of xxx
的吧.

第一次remove_proc_entry的时候删不掉,仅仅是设了个deleted而已.
而当该文件读完毕的时候,会调用到proc_delete_inode,最终free掉proc entry.

frank_seng

原帖由 netentsec 于 2008-1-15 13:36 发表
拿ip_conntrack为例，
在流量非常大的时候，cat /proc/net/ip_conntrack需要很长的时间，
如果cat返回之前，如果执行rmmod ip_conntrack会不会有问题？

以2.6.15为例，ip_conntrack_standalone.c 的简化框 ...

保证卸载时模块的MOD COUNT计数为0就可以

baohuaihuai

新版本的kernel似乎在proc_dir_entry中没有deleted这个域了,会一直等到unload完成才会free掉proc entry