写块设备文件时，如果这个块设备已被安装，如何互斥

Question

我看的是2.4.32，有个地方想不明白

当一个块设备被mount后，至少有三种途径可以读写这个块设备上的块

1) 读写这个块设备上的普通文件，实际操作就是读写以( inode, index) 确定的唯一缓存页，在读写过程中，持有inode->i_sem，page锁定 ，这是在VFS层的锁。
如果遇到文件的“洞”，需要分配新块时，内核会访问块缓存，还会另外加上一个lock_kernel 锁

2）内核有一些修改块，inode位图等的操作，这些操作都不经过VFS，而直接到达具体的文件系统，内核的对策是只加lock_kernel锁，然后就开始操作块缓存中的buffer_head。
如果整个操作完成前，本进程睡眠的话，在唤醒后还需要重新校验一次，例如verify_chain等，校验buffer_head中的内容是否有改变

3) 读写在另一个设备上的，代表着被mount的这个块设备的设备文件，过程类似于 1) ，持同样的VFS层的锁。
但是这个缓存页非常不同，1) 中的缓存页是普通文件的缓存页，page上关联的buffer_head，肯定不在buffer_head 的hash 表中；
但是2) 中是一个设备文件的缓存页，块设备文件缓存页既处于页缓存中；页上关联的buffer_head也就是理论上的，buffer_head的hash 表中，这个块设备的所有块缓存

现在问题是在SMP上

1） 1并发或者2并发的话，都没有问题，他们需要持有同样的lock_kernel锁才能操作，并且睡眠再唤醒后，有一个类似于verify_chain这样的校验操作

2） 3 并发也没有问题，两个进程都需要inode->i_sem与page上的锁

3） 1，2 并发的话，还没有问题，一旦访问buffer_head的hash表，还是需要lock_kernel，并且有睡眠后的校验操作

4） 1，3 并发的话，inode->i_sem属于两个inode，不能阻止；page也是页缓存中的两个page，不能阻止；3根本不需要访问buffer_head 的hash表，因此不会需要kernel_lock，还是不能阻止并发。

5） 2，3并发的话，2需要kernel_lock；3需要inode->i_sem和page上设lock，更是不能阻止并发。

4），5）中的这两个问题是怎么解决的？看了半天代码，也没看出来。

Answer 1

要沉了