feat(filesystem): Add tmpfs support and integrate with devfs

[fslongjin]

• Introduced a new tmpfs module for temporary file storage in memory.
• Updated devfs to mount /dev/shm as tmpfs, aligning with Linux semantics.
• Enhanced vfs module to include TMPFS_MAGIC for tmpfs identification.
• Added necessary methods and structures for tmpfs functionality, including inode management and file operations.

[fslongjin]

@claude review this pr in Chinese

[dragonos-community-ai-pr-reviewer]

Claude finished @fslongjin's task in 4m 3s —— View job

---

PR审查：添加tmpfs支持并与devfs集成

用户@fslongjin 要求用中文审查此PR。我将分析更改并提供代码审查反馈。

待办事项列表：

• 分析PR上下文和更改的文件
• 阅读相关代码文件以理解tmpfs实现
• 查看具体差异以了解修改内容
• 提供中文代码审查反馈

---

代码审查反馈

总体评价

这个PR实现了tmpfs内存文件系统，并将其与devfs集成，在/dev/shm挂载tmpfs以符合Linux语义。整体实现比较完整，代码结构清晰，符合项目现有模式。不过，我在审查过程中发现了一些可以改进的问题和潜在风险。

主要问题

1. tmpfs模块中的缓冲区长度检查逻辑问题

在kernel/src/filesystem/tmpfs/mod.rs:249-250和274-275的read_at和write_at方法中：

if buf.len() < len {
    return Err(SystemError::EINVAL);
}

这里的检查可能意图是确保缓冲区足够大，但len是调用者请求读取/写入的字节数，buf.len()是缓冲区的实际大小。实际上，在read_at的257-261行还有另一个检查：

if buf.len() < (end - start) {
    return Err(SystemError::ENOBUFS);
}

这导致了重复检查。建议统一逻辑：要么在方法入口检查buf.len() >= len，要么在计算实际拷贝大小时检查buf.len() >= (end - start)。当前实现可能会在buf.len() >= len但buf.len() < (end - start)时返回ENOBUFS，但end - start永远不会超过len（因为end = min(data.len(), offset + len)，start = min(data.len(), offset)），所以end - start <= len。因此第二个检查可能是多余的。

2. 未实现的设备节点类型

在mknod方法（kernel/src/filesystem/tmpfs/mod.rs:618-624）中，对于块设备(S_IFBLK)和字符设备(S_IFCHR)调用了unimplemented!()宏：

} else if mode.contains(InodeMode::S_IFBLK) {
    nod.0.lock().metadata.file_type = FileType::BlockDevice;
    unimplemented!()
} else if mode.contains(InodeMode::S_IFCHR) {
    nod.0.lock().metadata.file_type = FileType::CharDevice;
    unimplemented!()
}

这会导致运行时panic。tmpfs可能不需要支持这些设备类型，但应该返回适当的错误码（如ENOSYS或EINVAL）而不是panic。

3. 潜在的panic风险

在get_entry_name方法（kernel/src/filesystem/tmpfs/mod.rs:533-538）中，当多个子项具有相同inode_id时会触发panic：

_ => panic!(
    "Tmpfs get_entry_name: key.len()={key_len}>1, current inode_id={inode_id:?}, to find={to_find:?}",
    key_len = key.len(),
    inode_id = inode.metadata.inode_id,
    to_find = ino
),

虽然这种情况理论上不应发生，但在文件系统错误或并发问题下可能触发。考虑改为返回错误（如EIO）以增强鲁棒性。

4. mount.rs中的更改可能影响其他文件系统

在kernel/src/filesystem/vfs/mount.rs:1045-1049中，MountFS::super_block()方法的更改：

fn super_block(&self) -> SuperBlock {
    let mut sb = self.inner_filesystem.super_block();
    sb.flags = self.mount_flags.bits() as u64;
    sb
}

这个修改用mount标志覆盖了内部文件系统的super_block flags。这可能会影响依赖原始flags的其他代码。需要确认这是有意行为，且不会破坏现有功能。

5. 缺少内存限制检查

tmpfs实现支持通过size=挂载选项设置大小限制（kernel/src/filesystem/tmpfs/mod.rs:107-119），但在实际写入数据时（write_at方法）没有检查是否超出限制。虽然size_bytes存储在TmpfsMountData中，但在写入时未验证。需要添加配额检查。

次要问题和建议

1. 错误消息的一致性

在devfs的挂载tmpfs代码中（kernel/src/filesystem/devfs/mod.rs:805），使用了英文错误消息：

warn!("Mount /dev/shm failed: {:?}", e);

而项目中其他地方多使用中文注释。建议统一。

2. 硬编码的魔数

tmpfs魔数0x01021994（kernel/src/filesystem/vfs/mod.rs:1167）没有注释说明其来源或含义。建议添加注释解释选择该值的原因。

3. whitelist.txt更新

user/apps/tests/syscall/gvisor/whitelist.txt中添加了statfs_test，这是正确的，因为tmpfs需要statfs支持。

4. 代码重复

tmpfs的inode创建逻辑在多个地方重复（create_with_data、mknod等）。考虑提取公共函数以减少重复。

安全问题

未发现明显安全漏洞。但需要注意：

• tmpfs数据存储在内存中，没有加密
• 符号链接和文件数据大小未作限制（可能DoS攻击）
• 建议添加内存使用限制防止耗尽系统内存

测试建议

1. 测试tmpfs的基本文件操作（创建、读写、删除文件/目录）
2. 测试/dev/shm的挂载和访问
3. 测试tmpfs大小限制功能
4. 测试并发访问tmpfs文件
5. 测试statfs返回正确的tmpfs信息

总结

这是一个质量较高的PR，实现了核心功能并与现有系统良好集成。建议在合并前修复上述主要问题，特别是unimplemented!()panic和内存限制检查。

待办事项列表：

• 分析PR上下文和更改的文件
• 阅读相关代码文件以理解tmpfs实现
• 查看具体差异以了解修改内容
• 提供中文代码审查反馈

---

审查完成 - 请作者查看上述反馈，特别是主要问题部分。

[fslongjin]

@claude 上述pr审查我已经在5f2bb9b 里面修改。并且 “4. mount.rs中的更改可能影响其他文件系统” 这个地方本来就应该这么改，是你审查不对

[dragonos-community-ai-pr-reviewer]

Claude finished @fslongjin's task in 4m 33s —— View job

---

Claude开始处理@fslongjin的请求 —— 查看任务运行

用户@fslongjin指出已经在5f2bb9b提交中修改了之前审查中提到的问题，并指出第4点关于mount.rs的更改本来就应该那么改，是我审查不对。

待办事项列表：

• 检查当前分支和提交状态
• 查看5f2bb9b提交的具体修改内容
• 验证之前审查中提出的问题是否已修复
• 重新评估mount.rs的更改是否正确
• 提供更新后的审查反馈

---

更新后的审查反馈

感谢@fslongjin的澄清和修复。我已经检查了5f2bb9b提交，确认之前审查中提到的大部分问题已经得到修复，并且第4点关于mount.rs的更改确实是正确的。

问题修复状态验证

1. 缓冲区长度检查逻辑问题 ✅ 已修复

   • read_at方法中多余的if buf.len() < (end - start)检查已被移除
   • 保留了if buf.len() < len检查，这是正确的边界检查

2. 未实现的设备节点类型 ✅ 已修复

   • mknod方法中的unimplemented!()已改为return Err(SystemError::ENOSYS);
   • 避免了运行时panic，返回适当的错误码

3. 潜在的panic风险 ✅ 已修复

   • get_entry_name方法中的panic已改为Err(SystemError::EIO)
   • 增强了代码的鲁棒性

4. mount.rs中的更改 ✅ 正确实现

   • 经过重新评估，确认MountFS::super_block()方法用mount_flags覆盖内部文件系统的flags是正确的
   • SuperBlock的flags字段应该反映文件系统的挂载标志（如只读、noexec等）
   • 这个设计符合Linux语义，挂载标志应通过statfs系统调用暴露给用户空间

5. 缺少内存限制检查 ✅ 已实现

   • 新增了increase_size和decrease_size方法，使用原子操作管理文件系统大小
   • 在write_at、resize、truncate、unlink和rmdir方法中集成了大小检查
   • 当超过size=挂载选项指定的限制时返回ENOSPC错误

新增功能：原子大小管理

5f2bb9b提交引入了完整的原子大小管理机制：

• 线程安全：使用AtomicU64和compare_exchange_weak循环确保并发安全
• 精确配额：在文件写入、调整大小、截断和删除时动态更新当前使用量
• 错误处理：超过限制时返回ENOSPC（No space left on device）错误

代码质量改进

1. 错误处理一致性：使用统一的SystemError错误码
2. 内存安全：避免panic，使用适当的错误返回
3. 并发安全：原子操作保护共享状态
4. 资源管理：在文件删除时正确释放配额

总结

这个PR现在提供了一个完整、健壮的tmpfs实现：

1. 支持/dev/shm挂载，符合Linux标准
2. 实现了完整的文件操作（创建、读写、删除、重命名等）
3. 支持大小限制和原子配额管理
4. 与现有VFS架构良好集成
5. 修复了之前审查中的所有主要问题

建议合并此PR。

---

审查完成 - 所有问题已得到妥善解决，tmpfs实现符合预期质量标准。