Lockdep-1-相关文档翻译

一、lockdep-design.txt

注: 翻译自 msm-4.4/Documentation/locking/lockdep-design.txt

 

运行时持锁正确性验证器
=======================================

由 Ingo Molnar <mingo@redhat.com> 发起
由 Arjan van de Ven <arjan@linux.intel.com> 添加

1. 锁类

验证器操作的基本对象是锁的“类”。

锁类是一组逻辑上遵循相同锁定规则的锁，即使这些锁可能有多个（甚至可能是数万个）实例。例如，inode 结构体中的一个锁就是一个锁类，而每个 inode 都有其对应的锁类实例。

验证器跟踪锁类的'state'，并跟踪不同锁类之间的依赖关系。验证器维护一个滚动证明，以证明状态和依赖关系的正确性。

与锁实例不同，锁类本身永远不会消失：当锁类在启动后首次使用时，它会被注册，并且所有后续使用该锁类的操作都将附加到该锁类。

2. 状态

验证器将锁类的使用历史记录跟踪到 4n + 1 个独立的状态位中：

- “曾在 STATE 上下文中被持有”
- “曾在 STATE 上下文中被作为读锁持有”
- “曾在 STATE 启用的情况下被持有”
- “曾在 STATE 启用的情况下被作为读锁持有”

其中 STATE 可以是以下之一 (kernel/locking/lockdep_states.h)

- hardirq
- softirq
- reclaim_fs

- 'ever used' [ == !unused ]

当违反锁定规则时，这些状态位会显示在锁定错误消息中，并以花括号括起来。以下示例：

   modprobe/2287 is trying to acquire lock:
    (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24

   but task is already holding lock:
    (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24

位的位置表示上述每个状态的 STATE 和 STATE-read，每个状态中显示的字符表示：

   '.'  在关中断禁用且不在中断上下文中时获取
   '-'  在中断上下文中获取
   '+'  在开中断的情况下获取
   '?'  在开中断状态下在中断上下文中获取。

未使用的互斥锁不能成为导致错误的原因之一。

3. 单锁状态规则：

softirq-unsafe 的锁类也自动变为 hardirq-unsafe。以下状态互斥，每个锁类只能设置其中一种：

 <hardirq-safe> and <hardirq-unsafe>
 <softirq-safe> and <softirq-unsafe>

验证器会检测并报告违反这些单锁状态规则的锁使用情况。

4. 多锁依赖规则：

同一锁类不能被两次获取，因为这可能导致锁递归死锁。

此外，两个锁的获取顺序不能不同：

 <L1> -> <L2>
 <L2> -> <L1>

因为这可能导致锁反转而死锁。（验证器可以以任意复杂度找到此类依赖，即获取锁操作之间可以存在任何其他锁定顺序，验证器仍将跟踪锁之间的所有依赖关系。）

此外，任何两个锁类之间都不允许存在以下基于使用情况的锁依赖关系：

 <hardirq-safe>  ->  <hardirq-unsafe>
 <softirq-safe>  ->  <softirq-unsafe>

第一条规则源于这样一个事实：硬中断安全锁可能被硬中断上下文获取，从而中断硬中断不安全锁，并由此导致锁反转死锁。同样，软中断安全锁也可能在软中断上下文被获取，从而中断软中断不安全锁。

上述规则适用于内核中发生的任何锁定序列：获取新锁时，验证器会检查新锁与任何已持有的锁之间是否存在任何规则违规。

当锁类的状态发生变化时，上述依赖规则的以下方面将被强制执行：

- 如果发现新的硬中断安全锁，我们会检查它过去是否占用过任何硬中断非安全锁。

- 如果发现新的软中断安全锁，我们会检查它过去是否占用过任何软中断非安全锁。

- 如果发现新的硬中断非安全锁，我们会检查过去是否有任何硬中断安全锁占用过它。

- 如果发现新的软中断非安全锁，我们会检查过去是否有任何软中断安全锁占用过它。

（同样，我们进行这些检查也是基于这样的事实：中断上下文可能会中断任何非中断安全锁或非硬中断安全锁，这可能导致锁反转死锁——即使这种锁场景在实践中尚未触发。）

5. 例外：嵌套数据依赖导致嵌套锁定

Linux 内核有时会获取同一锁类的多个实例。这种情况通常发生在同类型的对象之间存在某种层次结构的情况下。在这种情况下，两个对象之间存在固有的“自然”顺序（由层次结构的属性定义），内核会按照这种固定顺序获取每个对象上的锁。

这种导致“嵌套锁定”的对象层次结构的一个例子是“整个磁盘”块设备对象和“分区”块设备对象；分区是整个设备的“一部分”，只要始终将整个磁盘锁视为高于分区锁的锁，锁定顺序就是完全正确的。验证器不会自动检测这种自然顺序，因为排序背后的锁定规则并非静态的。

为了教会验证器这种正确的使用模型，我们添加了各种锁定原语的新版本，允许您指定“嵌套级别”(需要写代码的人自己指定)。块设备互斥锁的示例调用如下所示：

enum bdev_bd_mutex_lock_class
{
    BD_MUTEX_NORMAL,
    BD_MUTEX_WHOLE,
    BD_MUTEX_PARTITION
};

mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION);

在这种情况下，锁定是在已知为分区的 bdev 对象上进行的。

验证器将以这种嵌套方式获取的锁视为单独的（子）类，以便进行验证。

注意：在更改代码以使用 _nested() 原语时，请务必小心并彻底检查层次结构是否已正确映射；否则可能会出现误报或漏报。

6. 100% 正确性证明：

验证器实现了完美的数学“闭包”（锁定正确性证明），即对于内核生命周期内至少发生过一次的每一个简单、独立的单任务锁定序列，验证器都能 100% 确定地证明这些锁定序列的任何组合和时序都不会导致任何类型的与锁定相关的死锁。[*]

也就是说，在实践中，复杂的多 CPU 和多任务锁定场景并不一定非要发生才能证明死锁：只需简单的“组件”锁定链至少发生一次（在任何时间、任何任务/上下文中），验证器就能证明其正确性。（例如，通常需要 3 个以上 CPU 以及极不可能发生的一系列任务、中断上下文和时序才能发生的复杂死锁，在普通的轻负载单 CPU 系统上也能检测到！）

这从根本上降低了内核中与锁定相关的 QA 的复杂性：在 QA 期间需要做的是在内核中触发尽可能多的“简单”单任务锁定依赖项，至少触发一次，以证明锁定的正确性——而不是触发 CPU 之间所有可能的锁定交互组合，以及所有可能的硬中断和软中断嵌套场景（这在实践中是不可能做到的）。

[*] 假设验证器本身 100% 正确，并且系统中任何其他部分都不会以任何方式破坏验证器的状态。我们还假设所有 NMI/SMM 路径（即使是禁用硬中断的代码路径也可能中断）都是正确的，并且不会干扰验证器。我们还假设系统中每个锁链的 64 位“链哈希”值都是唯一的。此外，锁递归次数不得超过 20。

7. 性能：

上述规则需要进行大量的运行时检查。如果我们对每个获取的锁和每个中断请求启用事件都进行检查，系统实际上会变得非常慢，无法使用。检查的复杂度为 O(N^2)，因此即使只有几百个锁类，我们也必须对每个事件进行数万次检查。

这个问题的解决方法是，只对任何给定的“锁定场景”（一个接一个地获取锁的唯一序列）进行一次检查。系统会维护一个简单的锁堆栈，并计算一个轻量级的 64 位哈希值，该哈希值对于每个锁链都是唯一的。当锁链首次被验证时，该哈希值会被放入哈希表中，该哈希表可以以无锁方式进行检查。如果之后再次出现该锁定链，哈希表会告诉我们无需再次验证该链。

8. 故障排除：

验证器最多可跟踪 MAX_LOCKDEP_KEYS 个锁类别。超过此数量将触发以下 lockdep 警告：

(DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))

默认情况下，MAX_LOCKDEP_KEYS 目前设置为 8191(1<<13-1)，而典型的桌面系统锁类别少于 1,000 个，因此此警告通常是由于锁类别泄漏或未能正确初始化锁造成的。这两个问题如下所示：

(1) 在运行验证器时反复加载和卸载模块会导致锁类泄漏。问题在于，每次加载模块都会为该模块的锁创建一组新的锁类，但卸载模块并不会删除旧的锁类（请参阅下文关于锁类重用的讨论以了解原因）。因此，如果反复加载和卸载该模块，锁类的数量最终会达到最大值。

(2) 使用包含大量未显式初始化锁的结构（例如数组）。例如，一个包含 8192 个 bucket 的哈希表，每个 bucket 都有自己的 spinlock_t 类型，将占用 8192 个锁类，除非每个自旋锁在运行时都显式初始化，例如使用运行时 spin_lock_init() 而不是编译时初始化函数（例如 __SPIN_LOCK_UNLOCKED()）。如果未能正确初始化每个 bucket 的自旋锁，将导致锁类溢出。相反，如果循环对每个锁都调用 spin_lock_init()，则会将所有 8192 个锁放入一个锁类中。

本文的寓意是，您应该始终显式初始化锁。

有人可能会认为应该修改验证器以允许锁类被重用。但是，如果您坚持这种观点，请首先检查代码并仔细考虑所需的更改，同时记住，要移除的锁类很可能与锁依赖关系图相关联。事实证明，这说起来容易做起来难。

当然，如果您的锁类确实用完了，接下来要做的就是找到有问题的锁类。首先，以下命令会显示当前正在使用的锁类数量以及最大值：

    grep "lock-classes" /proc/lockdep_stats

在中等配置的系统上，此命令的输出如下：

    lock-classes:    748 [max: 8191]

如果分配的数量（上文中为 748）随时间持续增加，则可能存在泄漏。可以使用以下命令识别泄漏的锁类：

grep "BD" /proc/lockdep

运行此命令并保存输出，然后与后续运行此命令的输出进行比较，以识别泄漏源。此输出还可以帮助您查找省略了运行时锁初始化的情况。

 

注: 最新官网资料: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html

二、lockstat.txt

注: 翻译自 msm-4.4/Documentation/locking/lockstat.txt

锁统计

- 功能

顾名思义，它提供锁的统计信息。

- 原因

因为锁争用之类的问题会严重影响性能。

- 实现方式

Lockdep 已经在锁函数中提供了钩子，并将锁实例映射到锁类。我们在此基础上进行构建（参见 Documentation/locking/lockdep-design.txt）。下图展示了锁函数与其中各种钩子之间的关系。

        __acquire
            |
           lock _____
            |        \
            |    __contended
            |         |
            |       <wait>
            | _______/
            |/
            |
       __acquired
            |
            .
          <hold>
            .
            |
       __release
            |
         unlock

lock, unlock  - the regular lock functions
__*  - the hooks
<>   - states

通过这些钩子，我们提供以下统计数据：

con-bounces - 涉及 x-cpu 数据的锁争用次数
contentions - 必须等待的锁获取次数
wait time min - 我们等待锁的最短(非0)时间
max - 我们等待锁的最长时间
total - 我们等待此锁的总时间
avg - 我们等待此锁的平均时间
acq-bounces - 涉及 x-cpu 数据的锁获取次数
acquisitions - 我们获取锁的次数
hold time min - 我们持有锁的最短(非0)时间
max - 我们持有锁的最长时间
total - 此锁被持有的总时间
avg - 此锁被持有的平均时间

这些数字是按锁类别、按读/写状态（适用时）收集的。

它还跟踪每个锁类别的 4 个争用点。争用点是指必须等待获取锁的调用点。

- 配置

锁统计信息可通过 CONFIG_LOCK_STAT 启用。

- 使用方法

启用统计信息收集：

# echo 1 >/proc/sys/kernel/lock_stat

禁用统计信息收集：

# echo 0 >/proc/sys/kernel/lock_stat

查看当前锁统计信息：
(实际输出中不包含行号，为了便于理解，以下解释已显示)

# less /proc/lock_stat

01 lock_stat version 0.4
02-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
03        class name   con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg
04-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
05
06  &mm->mmap_sem-W:            46             84           0.26         939.10       16371.53         194.90          47291        2922365           0.16     2220301.69 17464026916.32        5975.99
07  &mm->mmap_sem-R:            37            100           1.31      299502.61      325629.52        3256.30         212344       34316685           0.10        7744.91    95016910.20           2.77
08  ---------------
09    &mm->mmap_sem              1          [<ffffffff811502a7>] khugepaged_scan_mm_slot+0x57/0x280
19    &mm->mmap_sem             96          [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510
11    &mm->mmap_sem             34          [<ffffffff81113d77>] vm_mmap_pgoff+0x87/0xd0
12    &mm->mmap_sem             17          [<ffffffff81127e71>] vm_munmap+0x41/0x80
13  ---------------
14    &mm->mmap_sem              1          [<ffffffff81046fda>] dup_mmap+0x2a/0x3f0
15    &mm->mmap_sem             60          [<ffffffff81129e29>] SyS_mprotect+0xe9/0x250
16    &mm->mmap_sem             41          [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510
17    &mm->mmap_sem             68          [<ffffffff81113d77>] vm_mmap_pgoff+0x87/0xd0
18
19.......................................................................................................................................................................................................
20
21  unix_table_lock:           110            112           0.21          49.24         163.91           1.46          21094          66312           0.12         624.42       31589.81           0.48
22  ---------------
23  unix_table_lock             45          [<ffffffff8150ad8e>] unix_create1+0x16e/0x1b0
24  unix_table_lock             47          [<ffffffff8150b111>] unix_release_sock+0x31/0x250
25  unix_table_lock             15          [<ffffffff8150ca37>] unix_find_other+0x117/0x230
26  unix_table_lock              5          [<ffffffff8150a09f>] unix_autobind+0x11f/0x1b0
27  ---------------
28  unix_table_lock             39          [<ffffffff8150b111>] unix_release_sock+0x31/0x250
29  unix_table_lock             49          [<ffffffff8150ad8e>] unix_create1+0x16e/0x1b0
30  unix_table_lock             20          [<ffffffff8150ca37>] unix_find_other+0x117/0x230
31  unix_table_lock              4          [<ffffffff8150a09f>] unix_autobind+0x11f/0x1b0

此摘录显示了前两个锁类的统计信息。第 01 行显示输出版本 - 每次格式更改时，此版本都会更新。第 02-04 行显示带有列描述的标题。第 05-18 行和第 20-31 行显示实际统计信息。这些统计信息分为两部分：实际统计信息由短分隔符（第 08 行和第 13 行）与争用点分隔。

第 09-12 行显示记录的前 4 个争用点（尝试获取锁的代码），第 14-17 行显示记录的前 4 个争用点（锁持有者）。统计信息中可能缺少最大争用次数点。

第一个锁（第 05-18 行）是读/写锁，在短分隔符上方显示两行。争用点与列描述符不匹配，它们有两个：争用和 [<IP>] 符号。第二组争用点是我们正在争用的点。

时间值的整数部分以 us 为单位。

处理嵌套锁时，可能会出现以下子类：

32...................................................................................................................................................................................................
33
34        &rq->lock:       13128          13128           0.43         190.53      103881.26           7.91          97454        3453404           0.00         401.11    13224683.11           3.82
35        ---------
36        &rq->lock          645          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
37        &rq->lock          297          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
38        &rq->lock          360          [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a
39        &rq->lock          428          [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb
40        ---------
41        &rq->lock           77          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
42        &rq->lock          174          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
43        &rq->lock         4715          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
44        &rq->lock          893          [<ffffffff81340524>] schedule+0x157/0x7b8
45
46...................................................................................................................................................................................................
47
48      &rq->lock/1:        1526          11488           0.33         388.73      136294.31          11.86          21461          38404           0.00          37.93      109388.53           2.84
49      -----------
50      &rq->lock/1        11526          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
51      -----------
52      &rq->lock/1         5645          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
53      &rq->lock/1         1224          [<ffffffff81340524>] schedule+0x157/0x7b8
54      &rq->lock/1         4336          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
55      &rq->lock/1          181          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a

第 48 行显示了 &rq->lock 类（子类从 0 开始）的第二个子类 (/1) 的统计信息，因为在这种情况下，正如第 50 行所示，double_rq_lock 实际上获取了两个自旋锁的嵌套锁。

查看竞争最激烈的锁：

# grep : /proc/lock_stat | head
                 clockevents_lock:       2926159        2947636    0.15       46882.81  1784540466.34         605.41        3381345        3879161     0.00        2260.97    53178395.68          13.71
              tick_broadcast_lock:        346460         346717    0.18        2257.43    39364622.71         113.54        3642919        4242696     0.00        2263.79    49173646.60          11.59
           &mapping->i_mmap_mutex:        203896         203899    3.36      645530.05 31767507988.39      155800.21        3361776        8893984     0.17        2254.15    14110121.02           1.59
                        &rq->lock:        135014         136909    0.18         606.09      842160.68           6.15        1540728       10436146     0.00         728.72    17606683.41           1.69
        &(&zone->lru_lock)->rlock:         93000          94934    0.16          59.18      188253.78           1.98        1199912        3809894     0.15         391.40     3559518.81           0.93
                  tasklist_lock-W:         40667          41130    0.23        1189.42      428980.51          10.43         270278         510106     0.16         653.51     3939674.91           7.72
                  tasklist_lock-R:         21298          21305    0.20        1310.05      215511.12          10.12         186204         241258     0.14        1162.33     1179779.23           4.89
                       rcu_node_1:         47656          49022    0.16         635.41      193616.41           3.95         844888        1865423     0.00         764.26     1656226.96           0.89
&(&dentry->d_lockref.lock)->rlock:         39791          40179    0.15        1302.08       88851.96           2.21        2790851       12527025     0.10        1910.75     3379714.27           0.27
                       rcu_node_0:         29203          30064    0.16         786.55     1555573.00          51.74          88963         244254     0.00         398.87      428872.51           1.76

清除统计数据:

# echo 0 > /proc/lock_stat

三、RCU/lockdep.txt

注：翻译自 msm-4.4/Documentation/RCU/lockdep.txt

RCU 和 lockdep 检查

所有 RCU 类型都提供 lockdep 检查功能，因此 lockdep 能够感知每个任务何时进入和离开任何 RCU 类型的读端临界区。每种 RCU类型都会单独跟踪（但请注意，2.6.32 及更早版本并非如此）。这使得 lockdep 的跟踪能够包含 RCU 状态，这在调试死锁等问题时非常有用。

此外，RCU 还提供以下用于检查 lockdep 状态的原语：

    rcu_read_lock_held() for normal RCU(可抢占RCU).
    rcu_read_lock_bh_held() for RCU-bh.
    rcu_read_lock_sched_held() for RCU-sched.
    srcu_read_lock_held() for SRCU.

这些函数比较保守，因此如果不确定（例如，如果未设置 CONFIG_DEBUG_LOCK_ALLOC），则会返回 1。这可以防止在禁用 lockdep 时，诸如 WARN_ON(!rcu_read_lock_held()) 之类的函数产生误报。

此外，单独的内核配置参数 CONFIG_PROVE_RCU 可以检查 rcu_dereference() 原语：

rcu_dereference(p): 检查 RCU 读端临界区。

rcu_dereference_bh(p): 检查 RCU-bh 读端临界区。

rcu_dereference_sched(p): 检查 RCU-sched 读端临界区。

srcu_dereference(p, sp): 检查 SRCU 读端临界区。

rcu_dereference_check(p, c): 使用显式检查表达式“c”和 rcu_read_lock_held()。这在由 RCU 读取器和更新器调用的代码中很有用。

rcu_dereference_bh_check(p, c): 使用显式检查表达式“c”和 rcu_read_lock_bh_held()。这在由 RCU-bh 读取器和更新器调用的代码中很有用。

rcu_dereference_sched_check(p, c): 使用显式检查表达式“c”以及 rcu_read_lock_sched_held()。这在由 RCU-sched 读取器和更新器调用的代码中非常有用。

srcu_dereference_check(p, c): 使用显式检查表达式“c”和 srcu_read_lock_held()。这在由 SRCU 读取器和更新器调用的代码中很有用。

rcu_dereference_raw(p): 不进行检查。(尽量少用)

rcu_dereference_protected(p, c): 使用显式检查表达式“c”，并省略所有屏障和编译器约束。当数据结构无法更改时（例如，在仅由更新器调用的代码中），这很有用。

rcu_access_pointer(p): 返回指针的值并省略所有屏障，但保留防止重复或合并的编译器约束。这在测试指针本身的值（例如，是否为 NULL）时很有用。

rcu_dereference_check() 检查表达式可以是任何布尔表达式，但通常包含一个 lockdep 表达式。不过，任何布尔表达式都可以使用。以下是一个略显复杂的示例：

    file = rcu_dereference_check(fdt->fd[fd],
                    lockdep_is_held(&files->file_lock) ||
                    atomic_read(&files->count) == 1);

此表达式以 RCU 安全的方式获取指针“fdt->fd[fd]”，并且如果配置了 CONFIG_PROVE_RCU，则验证此表达式是否用于：

1. RCU 读端临界区(隐式)，或
2. 持有 files->file_lock，或
3. 非共享 files_struct。

在情况 (1) 中，指针以 RCU 安全的方式获取，用于原始 RCU 读端临界区；在情况 (2) 中，->file_lock 阻止任何更改发生；最后，在情况 (3) 中，当前任务是唯一访问 file_struct 的任务，同样阻止任何更改发生。如果上述语句仅从更新程序代码中调用，则可以改写如下：

    file = rcu_dereference_protected(fdt->fd[fd],
                     lockdep_is_held(&files->file_lock) ||
                     atomic_read(&files->count) == 1);

这将验证上述情况 #2 和 #3，此外，如果在 RCU 读端临界区中使用此方法，lockdep 会报错，除非上述两种情况之一成立。由于 rcu_dereference_protected() 忽略了所有屏障和编译器约束，因此它比其他类型的 rcu_dereference() 生成的代码更好。另一方面，如果 RCU 保护的指针或其指向的 RCU 保护的数据可以并发更改，则使用 rcu_dereference_protected() 是非法的。

目前只有 rcu_assign_pointer() 和 RCU 列表/树遍历原语的“通用”版本，它们（尚）不检查是否处于 RCU 读端临界区。未来可能会创建这些原语的单独版本。

 

四、RCU/lockdep-splat.txt

注: 翻译自 msm-4.4/Documentation/RCU/lockdep-splat.txt

Lockdep-RCU 于 2010 年初添加到 Linux 内核中
(http://lwn.net/Articles/371986/). 此功能用于检查 RCU API 的一些常见误用，最明显的是使用 rcu_dereference() 系列函数访问未进行适当保护的应受 RCU 保护的指针####。检测到此类误用时，会发出 lockdep-RCU splat 错误。

lockdep-RCU slat 的常见原因是有人访问受 RCU 保护的数据结构时，既没有 (1) 处于正确类型的 RCU 读端临界区，也没有 (2) 持有正确的更新端锁。因此，这个问题可能非常严重：它可能会导致随机内存覆盖甚至更糟的情况。当然，也可能存在误报，毕竟这就是现实世界的情况。

让我们来看一个来自 3.0-rc5 的 RCU lockdep splat 示例，这个示例早已被修复：

===============================
[ INFO: suspicious RCU usage. ]
-------------------------------
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!

其他可能有助于我们调试的信息：

rcu_scheduler_active = 1, debug_locks = 0
3 locks held by scsi_scan_6/1552:
 #0:  (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
scsi_scan_host_selected+0x5a/0x150
 #1:  (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
elevator_exit+0x22/0x60
 #2:  (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
cfq_exit_queue+0x43/0x190

stack backtrace:
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
Call Trace:
 [<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
 [<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
 [<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
 [<ffffffff812a5046>] elevator_exit+0x36/0x60
 [<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
 [<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
 [<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
 [<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
 [<ffffffff817da069>] ? error_exit+0x29/0xb0
 [<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
 [<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
 [<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
 [<ffffffff817da069>] ? error_exit+0x29/0xb0
 [<ffffffff812bcc60>] ? kobject_del+0x40/0x40
 [<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
 [<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
 [<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
 [<ffffffff8145f170>] do_scan_async+0x20/0x160
 [<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
 [<ffffffff810975b6>] kthread+0xa6/0xb0
 [<ffffffff817db154>] kernel_thread_helper+0x4/0x10
 [<ffffffff81066430>] ? finish_task_switch+0x80/0x110
 [<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
 [<ffffffff81097510>] ? __init_kthread_worker+0x70/0x70
 [<ffffffff817db150>] ? gs_change+0xb/0xb

Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:

    if (rcu_dereference(ioc->ioc_data) == cic) {

这种形式表明它必须位于普通的 RCU 读端临界区中，但上面的“其他信息”列表显示情况并非如此。相反，我们持有三个锁，其中一个可能与 RCU 相关。也许那个锁确实保护了这个引用。如果是这样，解决方法是通知 RCU，或许可以通过修改 __cfq_exit_single_io_context() ，使其接受 cfq_exit_queue() 中的 struct request_queue "q" 作为参数，这样我们就可以像下面这样调用 rcu_dereference_protected 了：

    if (rcu_dereference_protected(ioc->ioc_data,
                      lockdep_is_held(&q->queue_lock)) == cic) {

进行此更改后，如果此代码是在 RCU 读端临界区内调用，或者在 ->queue_lock 持有的情况下调用，就不会引发 lockdep-RCU splat。具体来说，由于 ->queue_lock 已持有（参见上面列表中的第 2 项），这将抑制上述 lockdep-RCU splat。

另一方面，我们或许确实需要一个 RCU 读端临界区。在这种情况下，临界区必须跨越 rcu_dereference() 返回值的使用范围，或者至少要跨越到引用计数增加或类似情况发生为止。处理此问题的一种方法是添加 rcu_read_lock() 和 rcu_read_unlock()，如下所示：

    rcu_read_lock();
    if (rcu_dereference(ioc->ioc_data) == cic) {
        spin_lock(&ioc->lock);
        rcu_assign_pointer(ioc->ioc_data, NULL);
        spin_unlock(&ioc->lock);
    }
    rcu_read_unlock();

经过此更改后，rcu_dereference() 始终位于 RCU 读端临界区内，这同样会抑制上述 lockdep-RCU splat。

但在这种特殊情况下，我们实际上并没有引用 rcu_dereference() 返回的指针。相反，我们只是将该指针与 cic 指针进行比较，这意味着 rcu_dereference() 可以用 rcu_access_pointer() 替换，如下所示：

if (rcu_access_pointer(ioc->ioc_data) == cic) {

由于在无保护的情况下调用 rcu_access_pointer() 是合法的，因此此更改也会抑制上述 lockdep-RCU splat。

 

 

优秀BK:

Linux死锁检测-Lockdep: https://www.cnblogs.com/arnoldlu/p/8580387.html //有实验
Linux soft lockup分析: https://www.cnblogs.com/arnoldlu/p/10338850.html //Lockup应该是Lockdep的延伸