【OLK-6.6】【主线补丁回合】fs: Avoid grabbing sb->s_umount under bdev->bd_holder_lock

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd1464105cb37a3b50a72c1d2902e97a71950af8

这个补丁修复了一个与锁顺序相关的潜在lockdep告警问题，相关讨论如下：

https://lore.kernel.org/linux-fsdevel/0000000000001825ce06047bf2a6@google.com/T/#u

### 问题背景

> "Fwiw, this was always a false-positive. But we also reworked the locking that even the false-positive cannot be triggered anymore. So yay!"

这个问题涉及锁定顺序的不一致性。

具体来说，问题出在：
- 块设备持有者操作（如`fs_bdev_mark_dead()`和`fs_bdev_sync()`）在持有`bdev->bd_holder_lock`锁的同时获取`sb->s_umount`信号量
- 这创建了`disk->open_mutex -> sb->s_umount`的锁顺序依赖
- 然而在其他代码路径中，锁的获取顺序可能相反，这违反了通常的"先高级锁(文件系统)，后低级锁(块层)"的原则

lockdep (Linux内核的死锁检测器)检测到了这种潜在的锁循环依赖，并发出警告。

### 补丁修复方式

补丁引入了`bdev_super_lock_shared()`函数，实现了一种安全的锁转换机制：

1. 使用这个新函数替代原来直接在持有`bd_holder_lock`的情况下获取`s_umount`的方式
2. 新函数的工作方式是：
   - 接受参数`bdev`并且要求调用者持有`bdev->bd_holder_lock`
   - 临时增加超级块的引用计数(防止其被释放)
   - 释放`bdev->bd_holder_lock`
   - 然后尝试获取`sb->s_umount`锁
   - 如果成功获取锁并且超级块仍然有效，则返回超级块，否则返回NULL

这样避免了同时持有两个锁的问题，解决了锁顺序的冲突。

**二、缺陷分析结构反馈**
影响性分析说明：

缺陷严重等级:(Critical/High/Moderate/Low)

缺陷根因说明:

受影响版本排查(受影响/不受影响):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1

修复是否涉及abi变化(是/否):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1

GVP openEuler/kernel

内容风险标识

评论 (2)

GVPopenEuler/kernel

内容风险标识