Add assertion in BitmapPageAllocator::init

[Copilot]

BitmapPageAllocator::init panics when initialized with a non-zero start address at maximum capacity (256MB default). The base address is always aligned down to 1GB boundaries, creating a gap that exhausts bitmap capacity before the requested region fits.

Changes

• Added explicit capacity check: Added assertion that panics with a clear error message when the bitmap capacity is insufficient for the requested allocation range
• Maintains 1GB alignment: Base address remains aligned to MAX_ALIGN_1GB to support maximum alignment capabilities
• Updated tests:
  • Preserved test_init_capacity_exceeded to verify the new panic path
  • Removed redundant test_init_nonzero_start_address and test_init_with_1gb_aligned_start because their behavior is already covered by existing test_bitmap_page_allocator_size_2g

Example

// Previously panicked with cryptic assertion from inner BitAlloc
let mut allocator = BitmapPageAllocator::<4096>::new();
allocator.init(40960, 256 * 1024 * 1024);  
// Now panics with clear message: "bitmap capacity exceeded: need X pages but CAP is Y"

// Allocations within capacity work fine
allocator.init(40960, 4 * 1024 * 1024);  // Succeeds

The fix ensures users get immediate, informative feedback when their configuration exceeds bitmap capacity, rather than encountering an obscure assertion failure from the underlying bitmap allocator.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>BitmapPageAllocator::init assertion fails in default feature settings</issue_title>
<issue_description>Hi! I believe I have found a problem in BitmapPageAllocator. To reproduce the problem, use the following code snippet and compile it with default feature settings.

fn test_alloc(){
        let mut allocator = BitmapPageAllocator::<4096>::new();
        let size = 256 * 1024 * 1024; // 256 MB size
        let start_addr = 40960; // can be any non-zero addr
        allocator.init(start_addr, size); // assertion failed: end <= Self::CAP
}

I believe it is a bug, because it is the normal behavior that the allocatable address index is not started from zero (zero means null, so it causes a lot of trouble).

I have investigated the reason for this bug. It turns out that the BitmapPageAllocator::inner only reserves the exact capacity of 256 MB (the maximum supported allocatable memory in default feature settings). It assumes the index of allocatable pages is started from zero. However, in BitmapPageAllocator::init, the start index of allocatable pages is calculated by start - self.base, where self.base is aligned down to 1GB. This creates an empty index before the index of the first allocatable page and causes an assertion failure.

To address the bug, I think the implementation should either add an alignment requirement for the start address or modify the way the start index is calculated.</issue_description>

<agent_instructions>try to fix this issue</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes BitmapPageAllocator::init assertion fails in default feature settings #9

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[equation314]

@copilot Panic if CAP does not meet the size or alignment requirement of start.

[Copilot]

@copilot Panic if CAP does not meet the size or alignment requirement of start.

Changed to panic with a clear error message when bitmap capacity is exceeded. Added test test_init_capacity_exceeded to verify the panic behavior. See commit 25886e7.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/arceos-org/slab_allocator/commits/v0.3.1
  • Triggering command: /home/REDACTED/.rustup/toolchains/stable-x86_64-REDACTED-linux-gnu/bin/cargo /home/REDACTED/.rustup/toolchains/stable-x86_64-REDACTED-linux-gnu/bin/cargo test --lib --features bitmap bitmap:: (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[AsakuraMizu]

@copilot Please check if test_init_nonzero_start_address and test_init_with_1gb_aligned_start have been covered by previous tests. If so, you can delete them. test_init_capacity_exceeded can be preserved.

[Copilot]

@copilot Please check if test_init_nonzero_start_address and test_init_with_1gb_aligned_start have been covered by previous tests. If so, you can delete them. `test_init_capacity_exc...

Done in 0e9969b. I verified those two tests were redundant with test_bitmap_page_allocator_size_2g, removed test_init_nonzero_start_address and test_init_with_1gb_aligned_start, and kept test_init_capacity_exceeded.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/arceos-org/slab_allocator/commits/v0.3.1
  • Triggering command: /home/REDACTED/.rustup/toolchains/nightly-x86_64-REDACTED-linux-gnu/bin/cargo /home/REDACTED/.rustup/toolchains/nightly-x86_64-REDACTED-linux-gnu/bin/cargo test --lib --features bitmap bitmap:: (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)