-
Notifications
You must be signed in to change notification settings - Fork 3
refactor: 清理跨模块架构常量访问 #254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -166,6 +166,9 @@ pub trait VirtualMemory: CpuOps + Sized { | |
| /// 对于直接映射,`paddr + PAGE_OFFSET = vaddr`。 | ||
| const PAGE_OFFSET: usize; | ||
|
|
||
| /// 用户地址空间最高可访问地址 | ||
| const USER_TOP: usize; | ||
|
Comment on lines
+169
to
+170
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To fully achieve the goal of converging architecture constants and reducing leakage of the constant module, consider adding USER_BASE to the VirtualMemory trait as well. Currently, constant::USER_BASE is still accessed directly in the impl_arch! macro. This ensures consistency with how other architectural constants like USER_TOP are handled. References
|
||
|
|
||
| /// 获取全局内核地址空间 | ||
| fn kern_address_space() -> &'static SpinLock<Self::KernelAddressSpace>; | ||
| } | ||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -12,6 +12,9 @@ pub const USER_STACK_SIZE: usize = 4 * 1024 * 1024; // 4MB | |||||
|
|
||||||
| pub const MAX_ARGV: usize = 256; | ||||||
|
|
||||||
| use crate::arch::{ArchImpl, virtual_memory::VirtualMemory}; | ||||||
| use crate::util::address::align_down; | ||||||
|
|
||||||
| // User space memory layout constants | ||||||
| // Memory layout (from high to low address): | ||||||
| // [USER_STACK] <-- | ||||||
|
|
@@ -20,13 +23,15 @@ pub const MAX_ARGV: usize = 256; | |||||
| // [USER_DATA] | ||||||
| // [USER_TEXT] | ||||||
|
|
||||||
| pub const USER_STACK_TOP: usize = SV39_BOT_HALF_TOP - PAGE_SIZE; // leave another guard page | ||||||
| /// Leave one guard page below the top of the user address space. | ||||||
| pub const USER_STACK_TOP: usize = <ArchImpl as VirtualMemory>::USER_TOP - PAGE_SIZE; | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The current calculation USER_TOP - PAGE_SIZE results in a non-page-aligned address (e.g., 0x...EFFF if USER_TOP is 0x...FFFF). This is unconventional for a stack top and may lead to alignment issues or unexpected behavior in memory mapping. It should typically be page-aligned. If the intention is to place the stack immediately below the trampoline page, it should be aligned to the page boundary.
Suggested change
|
||||||
|
|
||||||
| /// Userspace rt_sigreturn trampoline address (one RX page). | ||||||
| /// | ||||||
| /// Must not overlap with the user stack mapping. With the current (non page-aligned) `USER_STACK_TOP`, | ||||||
| /// the stack mapping ends at `align_down(SV39_BOT_HALF_TOP, PAGE_SIZE)`, so we place the trampoline there. | ||||||
| pub const USER_SIGRETURN_TRAMPOLINE: usize = SV39_BOT_HALF_TOP & !(PAGE_SIZE - 1); | ||||||
| /// the stack mapping ends at `align_down(USER_TOP, PAGE_SIZE)`, so we place the trampoline there. | ||||||
| pub const USER_SIGRETURN_TRAMPOLINE: usize = | ||||||
| align_down(<ArchImpl as VirtualMemory>::USER_TOP, PAGE_SIZE); | ||||||
|
|
||||||
| /// Maximum heap size (prevent OOM) | ||||||
| pub const MAX_USER_HEAP_SIZE: usize = 64 * 1024 * 1024; // 64MB | ||||||
|
|
@@ -40,5 +45,3 @@ pub const EXT4_BLOCK_SIZE: usize = 4096; | |||||
| pub const VIRTIO_BLK_SECTOR_SIZE: usize = 512; | ||||||
| /// 文件系统镜像大小 (与 qemu-run.sh 中的 fs.img 大小一致) | ||||||
| pub const FS_IMAGE_SIZE: usize = 1024 * 1024 * 1024; // 1 GB | ||||||
|
|
||||||
| use crate::arch::constant::SV39_BOT_HALF_TOP; | ||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -6,8 +6,7 @@ | |||||
| use alloc::vec::Vec; | ||||||
| use core::mem::MaybeUninit; | ||||||
|
|
||||||
| use crate::arch::constant::USER_TOP; | ||||||
| use crate::arch::{Arch, address::UA}; | ||||||
| use crate::arch::{Arch, ArchImpl, address::UA, virtual_memory::VirtualMemory}; | ||||||
|
|
||||||
| /// 向用户空间写入数据 | ||||||
| /// # 参数 | ||||||
|
|
@@ -104,7 +103,7 @@ impl UserBuffer { | |||||
| let Some(end) = start.checked_add(self.len) else { | ||||||
| return false; | ||||||
| }; | ||||||
| end <= USER_TOP | ||||||
| end <= <ArchImpl as VirtualMemory>::USER_TOP | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The check end <= USER_TOP is too strict. Since USER_TOP is defined as the "highest accessible address" (inclusive), a buffer that ends exactly at USER_TOP + 1 (meaning its last byte is at USER_TOP) should be considered valid. The current logic excludes the last byte of the user address space. if self.len == 0 {
return start <= <ArchImpl as VirtualMemory>::USER_TOP;
}
end - 1 <= <ArchImpl as VirtualMemory>::USER_TOP |
||||||
| } | ||||||
|
|
||||||
| /// 返回用户缓冲区长度 | ||||||
|
|
@@ -147,13 +146,13 @@ pub fn validate_user_ptr<T>(ptr: *const T) -> bool { | |||||
|
|
||||||
| // 检查起始地址是否在用户空间范围内 | ||||||
| // USER_BASE 为 0,所以只需检查上界 | ||||||
| if addr > USER_TOP { | ||||||
| if addr > <ArchImpl as VirtualMemory>::USER_TOP { | ||||||
| return false; | ||||||
| } | ||||||
|
|
||||||
| // 检查是否会溢出用户空间 | ||||||
| if let Some(end_addr) = addr.checked_add(size) { | ||||||
| if end_addr > USER_TOP + 1 { | ||||||
| if end_addr > <ArchImpl as VirtualMemory>::USER_TOP + 1 { | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Using ::USER_TOP + 1 can potentially overflow if USER_TOP is usize::MAX. While unlikely on current supported architectures, it is safer and more consistent with the logic in arch_impl.rs to use a subtraction-based check or handle the size > 0 case explicitly.
Suggested change
|
||||||
| return false; | ||||||
| } | ||||||
| } else { | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If USER_BASE is added to the VirtualMemory trait, it should be implemented here in the macro to maintain consistency with USER_TOP and existing architecture implementations.
References