高手指点:为什么可以在任何上下文调用dev_get_by_name()

kyok520

为什么可以在任何上下文调用dev_get_by_name()?
在内核源码里面
struct net_device *dev_get_by_name(struct net *net, const char *name)
{
        struct net_device *dev;

        read_lock(&dev_base_lock);
        dev = __dev_get_by_name(net, name);
        if (dev)
                dev_hold(dev);
        read_unlock(&dev_base_lock);
        return dev;
}
该函数是要去拿dev_base_lock这个读写锁的。而dev_base_lock这个读写锁的所有写操作只是禁止了软中断，并没有禁止中断。那么如果在isr中调用dev_get_by_name()。而dev_base_lock这个锁又恰好被一个写操作获得了锁，这个时候不会死锁吗?

请教高手指点

daniel_11

确实有点怪啊，除非这个锁只是用在软中断？所以锁软中断就够了？ 同问求解！

瀚海书香

回复 1# kyok520

该函数是要去拿dev_base_lock这个读写锁的。而dev_base_lock这个读写锁的所有写操作只是禁止了软中断，并没有禁止中断。那么如果在isr中调用dev_get_by_name()。而dev_base_lock这个锁又恰好被一个写操作获得了锁，这个时候不会死锁吗?

恩。貌似dev_get_by_name应该不能再中断上下文中调用。
   

yevv

如果写操作所在的进程 和 ISR是在同一个CPU上运行的话，那么写操作所在的进程应该可以迁移到其他CPU上运行吧

瀚海书香

回复 4# yevv

如果写操作所在的进程 和 ISR是在同一个CPU上运行的话，那么写操作所在的进程应该可以迁移到其他CPU上运行吧

首先是不会自动迁移的其他CPU的，况且如果只有一个CPU呢？
作者原来的注释是错的。


   

瀚海书香

回复 1# kyok520

The authors have confirmed our doubts!

The comment is wrong.
net/  has essentially no functions which can be called from hard irq context.
As matter of fact, there is only one: netif_rx(). Plus some trivial
library functions.
   

daniel_11

瀚海书香 发表于 2013-03-20 08:36
回复 1# kyok520

The authors have confirmed our doubts!

赞

kyok520

回复 6# 瀚海书香


    请问下你发的这个注释在哪里看到的?

瀚海书香

回复 8# kyok520
这不是哪里看到的。
是我跟netdev成员沟通的结果。这块我已经提交了patch，有人认为需要添加，但是Eric dumazet认为不需要。现在还在讨论是否放到comment中。

   

goter

瀚海书香 发表于 2013-03-23 10:05
回复 8# kyok520
这不是哪里看到的。
是我跟netdev成员沟通的结果。这块我已经提交了patch，有人认为需要 ...

目测你的changelog又要被喷