spin_lock_bh想到的一些事

最新推荐文章于 2024-03-07 18:17:59 发布
最新推荐文章于 2024-03-07 18:17:59 发布
阅读量4.7k 收藏 14
点赞数 2
文章标签： spin_lock spin_lock_bh
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dog250/article/details/108784871
版权

近日有人问我为什么在PREROUTING这个NF HOOK点的function里需要使用spin_lock/unlock_bh而不是spin_lock/unlock来保护临界区。

面对这个问题，有点懵，说到spin_lock族，有很多系列接口：

  • spin_lock/spin_unlock
  • spin_lock_bh/spin_unlock_bh
  • spin_lock_irq/spin_unlock_irq
  • spin_lock_irqsave/spin_unlock_irqrestore
  • …

之所以有这么多，说白了就是为了 防止关闭了抢占的临界区被同一个CPU的高优先级序列打断而重入时造成死锁。

但还是要给出一个具体的case才能让人信服，而不仅仅是理论上如此。

其实只需要给出一个进程上下文调用PREROUTING function的case即可：

  1. 进程上下文C1在PREROUTING function中调用spin_lock(Lx)进入临界区。
  2. 尚未出临界区，C1所运行CPU被中断，随即调度softirq执行net_rx_action。
  3. 在软中断上下文C2中进入PREROUTING function，调用spin_lock(Lx)企图进入临界区。
  4. 由于C1已经获取spinlock Lx，C2开始自旋，等待C1释放Lx。
  5. 由于C1被C2抢占，而C2已经自旋，因此妥妥死锁！

但问题是，在什么情况下，进程上下文能到PREROUTING呢？？

记得2015年大概也是这个时候，写过一篇文章：
https://blog.csdn.net/dog250/article/details/48770481
该文章中的case是进程上下文中执行数据包接收的场景，数据包接收的过程中肯定是穿过PREROUTING点的。

我来摘抄一下该文章相关的描述：

一个连接本机的TCP数据包最终到达了loopback的xmit发送函数，其中简单的调度了本CPU上的一个软中断处理，然后会在下一次中断结束后调度其执行，这有很大几率是在当前发送进程的上下文中进行的，也就是说，发送进程在其上下文中进行了发送操作，而此时软中断借用了其上下文触发了接收操作，…

但是，有问题啊，什么叫 "这有很大几率是在当前发送进程的上下文中进行的" 我感觉这不严谨，所以今天我要深入探究一下这个问题：

  • 为什么loopback网卡的发送和接收逻辑在同一个进程上下文中进行？

为此，需要在本地通过loopback进行ping通信的时候，打印出stack：

#!/usr/local/bin/stap -g

function dump()
%{
	dump_stack();
%}

probe kernel.function("icmp_rcv")
{
	dump();
	//print_backtrace(); // 这个不知为何不好使..
}

以下是一次ping后的结果：

[34197.319729]  [<ffffffff8159a145>] ? icmp_rcv+0x5/0x380
[34197.319732]  [<ffffffff81561b84>] ? ip_local_deliver_finish+0xb4/0x1f0
[34197.319735]  [<ffffffff81561e69>] ip_local_deliver+0x59/0xd0
[34197.319738]  [<ffffffff81561ad0>] ? ip_rcv_finish+0x350/0x350
[34197.319741]  [<ffffffff815617fd>] ip_rcv_finish+0x7d/0x350
[34197.319744]  [<ffffffff81562196>] ip_rcv+0x2b6/0x410
[34197.319747]  [<ffffffff81561780>] ? inet_del_offload+0x40/0x40
[34197.319752]  [<ffffffff815267b2>] __netif_receive_skb_core+0x582/0x7d0
[34197.319755]  [<ffffffff81526a18>] __netif_receive_skb+0x18/0x60
[34197.319757]  [<ffffffff815276ee>] process_backlog+0xae/0x180
[34197.319760]  [<ffffffff81526ed2>] net_rx_action+0x152/0x240
[34197.319765]  [<ffffffff8107e02f>] __do_softirq+0xef/0x280
[34197.319768]  [<ffffffff81646b1c>] call_softirq+0x1c/0x30
[34197.319769]  <EOI>  [<ffffffff81017155>] do_softirq+0x65/0xa0
[34197.319777]  [<ffffffff8107d924>] local_bh_enable+0x94/0xa0
[34197.319780]  [<ffffffff81566a00>] ip_finish_output+0x1f0/0x7d0
[34197.319783]  [<ffffffff81567cff>] ip_output+0x6f/0xe0
[34197.319786]  [<ffffffff81566810>] ? ip_fragment+0x8b0/0x8b0
[34197.319789]  [<ffffffff81565971>] ip_local_out_sk+0x31/0x40
[34197.319791]  [<ffffffff81568746>] ip_send_skb+0x16/0x50
[34197.319793]  [<ffffffff815687b3>] ip_push_pending_frames+0x33/0x40
[34197.319797]  [<ffffffff81590fbe>] raw_sendmsg+0x59e/0x620
[34197.319802]  [<ffffffff810af1a9>] ? ttwu_do_wakeup+0x19/0xd0
[34197.319805]  [<ffffffff8159f604>] inet_sendmsg+0x64/0xb0
[34197.319811]  [<ffffffff8150cc90>] sock_sendmsg+0xb0/0xf0
[34197.319814]  [<ffffffff8150d201>] SYSC_sendto+0x121/0x1c0
[34197.319817]  [<ffffffff8150e221>] ? __sys_recvmsg+0x51/0x90
[34197.319820]  [<ffffffff8150dc8e>] SyS_sendto+0xe/0x10
[34197.319823]  [<ffffffff81645189>] system_call_fastpath+0x16/0x1b

哈哈，真相大白了！我在2015年的分析是错误的：

发送进程在其上下文中进行了发送操作，而此时软中断借用了其上下文触发了接收操作，…

根本就不是什么 "借用了其上下文" ，而是实实在在就是在该上下文中主动调用的net_rx_action啊！

其调用逻辑如下：

ip_output_finish
    rcu_read_lock_bh
    ...
        dev_queue_xmit
            loopback_xmit
                netif_rx
                    enqueue_to_backlog  # 这里将skb入队列
                        raise_softirq_irqoff(NET_RX_SOFTIRQ)
                    ...
                ...
            ...
        ...
    ...
    rcu_read_unlock_bh # unlock操作触发进程上下文中处理接收操作
        local_bh_enable
            do_softirq
                __do_softirq
                    net_rx_action # 这里对队列中的skb进行处理
                        ...
                        ip_rcv_finish
                            icmp_rcv
                        ...
                    ...
                ...
            ...
        ...
    ...
ip_output_finish return

OK，现在，这就是一个非常清晰的进程上下文执行数据包接收逻辑的case，也就是说：

  • 既然软中断函数net_rx_action可能会在进程上下文中执行，为了防止死锁，其中的临界区一定要用_bh版本的spinlock保护！

类似rcu_read_unlock_bh这种在unlock过程中做很多事情的操作，内核中还有很多：

  • spin_unlock可能会触发schedule进而发生task切换。
  • spin_unlock_bh可能会触发do_softirq进而执行软中断例程。
  • release_sock可能会执行sk_backlog_rcv进而处理收包。
  • …

这是一种 补偿 效应，既然lock操作到unlock操作之间禁止了一些行为，那么在unlock时就要尽可能地去补偿这些不得不延后的行为，尽量让它们马上执行。这个设计还是比较巧妙的。

另外，还有一个典型的进程上下文执行数据包接收逻辑的case，即TUN/TAP网卡从进程上下文调用tun_get_user，然后直接调用netif_rx_ni来收包的case。

我们再来看看这个loopback网卡发送和接收数据包奇怪且有意思的流程：

  • 发送逻辑尚未返回，接收逻辑先返回。

这意味着什么？不得而知，但如果碰到一些本机连本机过程中莫名其妙的问题，可以从此入手来排查。

浙江温州皮鞋湿，下雨进水不会胖。

dog250
关注
Linux内核自旋锁使用场景
新时代农民工
07-27 459
spin_lock、spin_lock_bh、spin_lock_irq和spin_lock_irqsave都是在内核中用于同步访问共享资源的锁。它们在不同的上下文中使用，并具有一些区别。
Linux内核自旋锁应用
新时代农民工
08-11 265
spin_lock、spin_lock_bh、spin_lock_irq和spin_lock_irqsave 都是用于实现自旋锁的函数。它们在不同的上下文环境中使用，具有不同的中断屏蔽级别和上下文切换机制。单核的话，只有发生中断会使任务被抢占，那么可以进入临界区之前先关中断，但是对多核CPU光关中断就不够了，因为对当前CPU关了中断只能使得当前CPU不会运行其它要进入临界区的程序，但其它CPU还是可能执行进入临界区的程序。
spin_lock_bh使用
Do one thing at a time, and do well.
01-04 3235
spin_lock_bh作用： 1.保护临界区 2.禁止抢占 3.禁止软中断 在软中执行函数_do_softirq()中已经使用__local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET)来禁止软中断了，所以CPU上执行软中断是串行执行的。 软中断的执行： 1.irq_exit()退出时可能会执行softirq 2.softirq的内核线程 spin_lock_bh()主要用于保护其他进程上下文访问软中断函数共享的变量。 软中断和进程B共享
spin_lock_bh
08-09 1222
一个软中断不会抢占另外一个软中断,softirq执行时preempt_count大于零，所以从中断返回到软中断的时候，不会调度   用lock_bh()，是因为这些netfilter hooks可以从系统调用的context到达， 比如socket的send_msg()是
spin_lock_bh（）与spin_unlock_bh（）
热门推荐
Macross的专栏
10-26 3万+
<br />spin_lock_bh通常用在进程中，用来禁止抢断和禁止软中断。<br /> <br />spin_lock_bh()中首先会调用local_bh_disable()禁止当前CPU的软件中断。而函数spin_unlock_bh()则调用local_bh_enable()来势能本地CPU的软件中断。在软件中断被禁止的时候，本地CPU的所有软中断都不会被执行。<br /> <br />如果一个softirq 与 用户上下文共享数据，就有两个问题：首先，当前的用户上下文可能被softirq中断；其次
linux内核 自旋锁+中断 spin_lock_bh/spin_unlock_bh
10-08 3242
spin_lock_bh通常用在进程中，用来禁止抢断和禁止软中断。 spin_lock_bh()中首先会调用local_bh_disable()禁止当前CPU的软件中断。而函数spin_unlock_bh()则调用local_bh_enable()来势能本地CPU的软件中断。在软件中断被禁止的时候，本地CPU的所有软中断都不会被执行。 如果一个softirq 与 用户上下文共享数据，就有两个问题：首先，当前的用户上下文可能被softirq中断；其次，临界区可能会在别的CPU进入。这时spin_lock_
spin_lock spin_lock_irq spin_lock_irqsave、spin_lock_bh
tangyongxiang_cn的博客
12-01 2595
1，为啥需要自旋锁 很多时候我们并不能采用其他的锁，比如读写锁、互斥锁、信号量等。一方面这些锁会发生上下文切换，他的时间是不可预期的，对于一些简单的、极短的临界区完全是一种性能损耗；另一方面在中断上下文是不允许睡眠的，除了自旋锁以外的其他任何形式的锁都有可能导致睡眠或者进程切换，这是违背了中断的设计初衷，会发生不可预知的错误。基于两点，我们需要自旋锁，他是不可替代的。 2，为啥自旋锁禁止抢占 这一点其实很好理解，当一个 CPU 获取到一把自旋锁之后，开始执行临界区代码，此时假设他的时间片运转完毕，..
自旋锁操作 spin_lock
12-11
4. `spin_lock_bh(spinlock_t *lock)`：与 `spin_lock` 类似，但在获取锁时会禁止软中断。适用于需要在持有锁的同时禁止软中断的场景。 5. `spin_unlock_bh(spinlock_t *lock)`：对应于 `spin_lock_bh` 的解锁操作，...
由CPU高负载引发内核探索之旅
j简说Linux的博客
11-23 420
最后，总结整个问题和定位过程，我们从一次CPU高负载问题出发，从最开始在问题机器上猜想和分析，找不到确切答案。通过比较不同机型函数实现差异找到关键点。再通过代码分析、复现验证、社区求证这三个方面将问题的前因后果分析清楚，最终给出了解决方案。t=M85B大厂面试题锦集+视频教程https://docs.qq.com/doc/DTlhVekRrZUdDUEpy。
linux源码之自旋锁(spinlock)/读写自旋锁分析
jkzzxQQQ的博客
11-16 802
本文kernel代码分析基于以下 1.linux-4.14.159 2.64bit代码处理逻辑 我们知道linux内核中存在进程、中断、软中断等相互之间的同步问题，在SMP下这些使用场景会变的尤为复杂，因此linux内核提供了semaphore、spinlock、mutex，rcu、atomic等锁机制来解决这些问题。然而每种锁机制都有不同的实现原理以使用场景，在性能方面也是会存在一定差异，因此对于不同场景下的问题我们能选择最适用的机制才是最好的。 此篇我们重点看下semaphore以及rw_semapho
释疑spin_lock_irq spin_lock_irqsave spin_unlock_irqrestore spin_lock_bh
江东风又起
12-23 2166
spin_lock_irq spin_lock_irqsave spin_unlock_irqrestore spin_lock_bh
spin_lock、spin_lock_bh、spin_lock_irq、spin_lock_irqsave的使用
一棵小草的空间
12-01 6367
概述 Spinlock的目的是用来同步SMP中会被多个CPU同时存取的变量。在Linux中，普通的spinlock由于不带额外的语义，用起来反而要非常小心。 在Linux kernel中执行的代码大体分normal和interrupt context两种。tasklet/softirq可以归为normal因为他们可以进入等待；nested interrupt是interrupt context的一...
互斥锁 spin_lock < spin_lock_bh < spin_lock_irq < spin_lock_irqsave
欧阳海宾
07-24 3462
Spinlock的目的是用来同步SMP中会被多个CPU同时存取的变量。在Linux中，普通的spinlock由于不带额外的语义，是用起来反而要非常小心。 在Linux kernel中执行的代码大体分normal和interrupt context两种。tasklet/softirq可以归为normal因为他们可以进入等待；nested interrupt是interrupt context的一种
Linux内核基础 - 同步锁机制之spin_lock全家桶
最新发布
sz66cm 学习随笔
03-07 995
linux kernel 同步锁机制 spinlock spin_lock
linux 自旋锁 spin_lock
08-07 770
linux 自旋锁        自旋锁非常简单，一个自旋锁就是一个互斥设备，它只有两个值：“锁定”与“解锁”，如果锁可用，则“锁定”位被设置，而代码继续进入临界区，相反，如果锁被其他人获得，则代码进入忙循环并重复检查这个锁，直到该锁可用为止，这个就是“自旋”的部份。
Linux内核原语（十二）——Spinlock与内核抢占
Hello Mr.Z的博客
04-18 1440
spin_lock与内核抢占 小狼@http://blog.csdn.net/xiaolangyangyang 内核抢占特性 2.6内核版本加入了抢占的特性，但我们可以配置为抢占和非抢占模式。 在单处理器2.6版本的非抢占模式下，spin_lock被编译为一条空语句，什么都不干； 在单处理器2.6版本的抢占模式下
互斥机制之自旋锁(spinlock)
tpmamba的博客
09-21 629
一、（基础）自旋锁 如果测试结果表明锁仍被占用，程序将在一个小的循环内重复这个“测试并设置”操作，即进行所谓的“自旋”。 1．定义自旋锁 spinlock_t spin; 2．初始化自旋锁 spin_lock_init(lock); //该宏用于动态初始化自旋锁lock。 3．获得自旋锁 spin_lock(lock); //该宏用于获得自旋锁lock。 //如果能立即获得锁，就马上返回；否则将自旋在那里，直到该自旋锁的保持者释放； spin_trylock(lock); //该宏尝试获得自旋锁lock。
【分析笔记】Linux 内核自旋锁的理解和使用原则
lovemengx的博客
07-25 983
Linux 内核自旋锁的理解和使用原则总结
spin_lock和spin_lock_irqsave的区别
06-08
spin_lock() 和 spin_lock_irqsave() 都是 Linux 内核中用于保护共享资源的自旋锁函数，它们的区别在于是否对中断进行处理。 spin_lock() 函数会获取自旋锁，并禁用本地 CPU 的中断。这意味着，如果在获取自旋锁的过程中发生了中断，中断处理程序将无法运行，直到自旋锁被释放。因此，spin_lock() 主要用于在中断被禁用的情况下保护共享资源，以防止其他 CPU 并发访问。 而 spin_lock_irqsave() 函数则会获取自旋锁，并保存本地 CPU 的中断状态。这意味着，在获取自旋锁的过程中，中断可以被触发，但是中断处理程序不能访问被保护的共享资源，因为它们也会尝试获取自旋锁。因此，spin_lock_irqsave() 主要用于在中断被启用的情况下保护共享资源。 在使用 spin_lock_irqsave() 函数时，需要在获取自旋锁的同时保存中断状态，并在释放自旋锁的同时恢复中断状态，以避免出现中断状态被篡改的情况。常见的用法是： ```c spinlock_t my_lock; unsigned long flags; spin_lock_irqsave(&my_lock, flags); // 获取自旋锁并保存中断状态 // 在这里进行对共享资源的访问 spin_unlock_irqrestore(&my_lock, flags); // 释放自旋锁并恢复中断状态 ``` 总之，spin_lock() 适用于在禁用中断的情况下保护共享资源，而 spin_lock_irqsave() 适用于在启用中断的情况下保护共享资源，它们的使用方式略有不同，需要根据具体情况选择合适的函数。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值