BKL 究竟用在什么時(shí)候 vfs里面的readdir 需要嗎

viton_xuan

有兩個(gè)問(wèn)題求教
一 BKL(Big kernel lock )
看 2.6.9 內(nèi)核
"include/linux/fs.h" 里面對(duì)file_operations前有段說(shuō)明
/*
* NOTE:
* read, write, poll, fsync, readv, writev can be called
*   without the big kernel lock held in all filesystems.
*/
意思是除他提到的幾個(gè)外， 其他的有可能要調(diào)用 BKL
而在 "Documentation/filesystems/Locking"里對(duì)file_operations的說(shuō)明
locking rules:
        All except ->poll() may block.
                        BKL
llseek:                 no      (see below)
read:                   no
aio_read:               no
write:                  no
aio_write:              no
readdir:                no
poll:                   no
ioctl:                  yes     (see below)
mmap:                   no
open:                   maybe   (see below)
flush:                  no
release:                no
fsync:                  no      (see below)
aio_fsync:              no
fasync:                 yes     (see below)
lock:                   yes
readv:                  no
writev:                 no
sendfile:               no
sendpage:               no
get_unmapped_area:      no
check_flags:            no
dir_notify:             no

好像是絕大部分都不需要 BKL
而ioctl等幾個(gè)是要的，就看了 sys_ioctl， 里面的確有 lock_kernel （）  unlock_kernel（）
想問(wèn)這個(gè)BKL究竟用在什么場(chǎng)合。  用來(lái)保護(hù)什么資源。

二  hook vfs里面的readdir。 之后rmmod， 在磁盤(pán)讀寫(xiě)比較密集時(shí)，會(huì)oops。 而一般空閑時(shí)正常
我是用 find / -name not _exist_file 進(jìn)行測(cè)試
rmmod之后
oops情況見(jiàn)附件

可能是正在有readdir的操作， 而剛好這時(shí)把指針替換了。 所以報(bào)錯(cuò)。 需要加什么同步保護(hù)機(jī)制可以防止這種情況呢？ 可是我看sys_read好像也沒(méi)檢查什么同步機(jī)制啊