fix(mm): 修复fat文件系统的PageCache同步问题 #1005
Conversation
|
@MemoryShore: no appropriate reviewer found, use |
|
这样的写法我感觉过度的把pagecache的逻辑跟fat本身的逻辑进行了耦合，而且耦合的很紧密啊（都涉及到了FAT写入文件的具体实现的函数那里了）。我认为这样写的不好，得把page cache的逻辑抽取出来。毕竟将来会有不同的文件系统。 @dragonosbot author |
dragonosbot
added
S-等待作者修改
我感觉也没有很耦合吧，pagecache的read和write就只接收一个offset和buf而已，别的文件系统也能用？ |
|
这耦合程度很深吧，你想想假如有10种文件系统，pagecache如果改动涉及写入的地方，就要改10个文件系统里面都改。而且，如果有10种不同的文件系统，你这里这段代码得复制10遍。从这个角度来看，这里是缺少抽象的。 |
|
貌似我好像没找到脏页回写机制？ |
page_writeback函数 |
|
|
kernel/src/mm/page.rs
Outdated
| if self.shared { | ||
| shm_manager_lock().free_id(&self.shm_id.unwrap()); | ||
| } | ||
| unsafe { |
There was a problem hiding this comment.
There was a problem hiding this comment.
第501行已经断言映射计数是0了，所以问题应该不大。
然后shared目前就只判断是否为共享页的。
deallocate_page_frames已经实现了释放shm_id，这里其实不需要释放了
不过要注意的是得保证同一块shm下的所有page必须一起释放，不能单独回收
kernel/src/mm/ucontext.rs
Outdated
| let mut page_guard = page.write_irqsave(); | ||
| page_guard.remove_vma(self); | ||
|
|
||
| // 如果物理页的vma链表长度为0并且未标记为不可回收，则释放物理页. | ||
| // TODO 后续由lru释放物理页面 | ||
| if page_guard.can_deallocate() { | ||
| if let PageType::Shm(shm_id) = page_guard.page_type() { | ||
| shm_manager_lock().free_id(shm_id); | ||
| } |
There was a problem hiding this comment.
我感觉这个会对同一个shmid，进行多次释放吧。这个应该不对？
There was a problem hiding this comment.
我感觉这个会对同一个shmid，进行多次释放吧。这个应该不对？
的确，这里可能会导致同一个shmid被多次释放
kernel/src/ipc/syscall.rs
Outdated
|
|
||
| // 映射计数减少 | ||
| kernel_shm.decrease_count(); | ||
|
|
||
| // 释放shm_id | ||
| if kernel_shm.map_count() == 0 && kernel_shm.mode().contains(ShmFlags::SHM_DEST) { | ||
| shm_manager_guard.free_id(shm_id); | ||
| } |
There was a problem hiding this comment.
这样不对吧？如果进程没有shmdt就退出了，那么映射计数就错了。产生资源泄露。
There was a problem hiding this comment.
这是上一个commit的，已经outdated了
@fslongjin
修复fat文件系统中调用read/write对文件进行读写时与缓存中的内容不同步的问题