在submit_bio处使用stapn

想着在submit_bio的地方，发现在guru模式下，stap是经常性地把内核整挂呀，不得已，也没有发现stap什么比较好的调试方法，所以索性直接使用stap的语法了，但是发现有问题呢，有的时候bv->bv_page->mapping->host, 我发现有的时候，这个地方得到的inode，然后我去解引用一下，竟然会导致失败，是因为bv->bv_page->mapping->host这条路山更有哪里是不合法的吗？有哪里是不合法的吗？

0:cron inode_add(0xffff8800a65fcbb0) ino(0) sector(436275808 +4096)
0:sh inode_add(0xffff8800a65fcbb0) ino(0) sector(176232464 +4096)

抓到了这样两条log，这两条log是说我我这个inode的inode->i_ino竟然是0

只要page在inode就在，inode在dentry就在！有这个结论么？

fs/inode.c函数中：prune_icache_sb

invalidate_mapping_pages，当有lock的page，writeback的page在的时候，读的时候，在submit_bio的地方page是lock的，写的时候这里是writeback的这个inode是不会被清理的，所以在submit_bio处读到的page，可以放心大胆地使用page->mapping->inode，这里有个问题，mapping一定是存在的吗？

这个address_space也是存放在函数

address_space应该是直接嵌入到inode里的一个结构，甚至都不是一个指针，看一下page_cache_get_page函数就可以了，拿一个最简单的f2fs_grab_cache_page来说，当往address_space里加东西的时候，是如何mapping是怎么得到的？

struct address_space *mapping = inode->i_mapping;

这个mappinp就是我们就是ｉｎｏｄｅ中嵌入的那个ｍａｐｐｉｎｇ的结构体

在inode初始化的时候：inode->i_mapping = mapping；ｍａｐｐｉｎｇ是怎么赋值的？struct address_space *const mapping = &inode->i_data;

所以只要ｉｎｏｄｅ在，那么我们通过page->address_space->host就一定能得到这个文件的inode，但是这个ｉｎｏｄｅ对应的ｄｅｎｔｒｙ是一定会在的吗？文件名从两个地方去读，一个是目录的数据块，一个是ｄｅｎｔｒｙ。但是ｄｅｎｔｒｙ一定会在吗？

fs/dcache.c: prune_dcache_sb

在这个函数中，当这个dentry仍然在使用的时候就不会被ｓｈｒｉｎｋ掉！dentry->d_lockref.count，这个值是啥时候+1呢

看下page后面的文件系统是啥 page->inode->i_sb->s_type->name

怎么通过ｉｎｏｄｅ得到文件名咧？

hard_link是啥呀？hark_link是一个inode上面挂了4个dentry，所以从inode，